Ethernet Frame Format and IEEE 802.3
Ethernet Frame Format
The format of an Ethernet data link frame, as defined in the DIX specification, is shown in the bottom portion of Figure 8. (If you need a reminder about the significance of the DIX specification, return to this chapter.) The upper portion shows the frame preceded by a preamble and Start Frame Delimiter (SFD), which are actually not part of the data link layer frame, but rather are related to the physical transmission.
Figure 8: Ethernet Frame Format
The preamble, consisting of seven bytes, is part of the data encoding process and is used for clock synchronization.
The Start Frame Delimiter consists of one byte and indicates where the useful information starts.
The data link frame itself has a minimum length of 64 bytes and a maximum length of 1518 bytes, including the header. As explained previously, the minimum length was defined to insure collision detection (according to the physical characteristics of the original Ethernet) by all stations, in the event that there is a collision, while a maximum length insures that no station occupies the "ether" for too much time.
This seems like the appropriate place to raise the matter of jumbo Ethernet frames. Because Ethernet these days is orders of magnitude faster than the original Ethernet, the limitation to 1500 bytes of data really doesn't make much sense, and Ethernet (and the systems that run it) would be more efficient with much larger frames. However, making such a change to a technology with such a large installed base is difficult. Nevertheless, much of the latest hardware supports jumbo frames, and there is support in operating systems. You can read a discussion about jumbo frames in this tutorial. Running an Ethernet with jumbo frames does not make so much sense if there is a lot of access to the Internet, because there is bound to be some Ethernet along the way (perhaps the Internet Service Provider) that does not support jumbo frames, and the path MTU (Maximum Transfer Unit) will be 1500, anyway. But in a private (virtual or otherwise) network, it might be a good idea.
The first two fields in the data link frame contain the source and destination addresses, each of which is 48 bits in length, represented as twelve hexadecimal digits. Since Ethernet is a broadcast medium, every station that is connected to the Ethernet receives every message. By examining the destination address, a station determines whether a frame is intended for itself. If it is not, the frame is discarded, unless the station is operating in "promiscuous mode", which means that it receives every frame. Packet capture software, such as Wireshark, uses the promiscuous mode to capture every frame that is on the Ethernet to which a computer is connected. In the next chapter, you will understand why these days you might only be able to capture the frames intended for your computer, the frames that were sent by your computer, and broadcast frames.
Destination addresses can either be unicast, broadcast, or multicast. Unicast addresses are intended for one particular station, and only one station on the Ethernet has that address. A station's unicast address is physically defined on its Ethernet adapter, unless a software override is used (which is an option, but not typically done). The adapter's physical address is not just unique on the Ethernet - it is globally unique (unless the card is a cheap card with a forged address). This is because each manufacturer is allocated a block of addresses by IEEE. The first three bytes (24 bits) in the address are the OUI (Organizationally Unique Identifier), which is purchased by the manufacturer from IEEE (which is why the manufacturers of cheap clones steal addresses). If you look at your Ethernet (or wireless LAN) address, you will be able to determine who manufactured the adapter. If you are using a Windows-based computer, you can do this with the ipconfig /all command at the command prompt. If you are using a Unix (or Linux) computer), you would use the ifconfig command, but since that command might not be in your path, you can include the path: /sbin/ifconfig.
Figure 9 shows the output from the ifconfig command that I entered in my free shell account on Arbornet's public server. Many free shell accounts are very restrictive as far as the commands that you can try, which is why I chose Arbornet, which permits users to use the ifconfig command.
Figure 9: Ifconfig Output
My output shows that the server I logged into has two (Fast) Ethernet interfaces, fxp0 and fxp1. I wrote "Fast" in parentheses because the fxp indicates certain Intel Fast Ethernet chipsets, and some of you - depending upon the configuration of the computer you are looking at - might see eth0 or some other interface type rather than fxp0. For example, OpenBSD interfaces are named for the type of card (e.g., fxp represents certain Intel Fast Ethernet chipsets) and not the type of interface. These details are not especially important to our discussion here.
The two Ethernet interfaces have the IEEE addresses 00:02:b3:93:c1:10 and 00:02:b3:93:c1:11. I called them "IEEE addresses" because the format for these addresses is in accordance with the IEEE 802 standards. This address standard is not just used for Ethernet, but is used for any type of LAN you are likely to come across. Though in the output we just examined, every pair of hexadecimal digits is separated by a colon, there is no standard method for writing the string of twelve hex digits. You might see them written as 00-01-b3-93-c1-10, or perhaps without any separation.
The first three bytes - six hex digits - are the OUI. If you take locate 00-01-b3 on the page that I just linked to, you'll see that it belongs to Intel. You can also find that Intel owns several blocks - over the years they have manufactured loads of Ethernet chipsets, and I assume they'll continue to do so, so they need lots of addresses.
The broadcast destination address consists of 48 bits (i.e., six bytes) of all ones. Since Ethernet addresses are represented in hexadecimal form, we'd see the 48 ones represented by FF-FF-FF-FF-FF-FF. A broadcast message is intended for all stations on the Ethernet, so that a station will always receive (rather than discard) broadcast messages, in addition to the unicast messages intended for that station.
Multicast messages are indicated by a one in the least significant bit in the first byte of the destination address. Thus, a multicast address might look like this: 01-xx-xx-xx-xx. A multicast address is intended for all stations that are members of a multicast group. So, a station's Ethernet controller would check a list of multicast groups to which the station belongs, and if the station is not in the group associated with that address, it would discard the frame. A common use of an Ethernet multicast address is for sending an IP message to an IP multicast group. A list of assigned Ethernet multicast addresses can be found here. A lot of what is listed there is no longer in use (though sometimes old equipment is still found in some installations) - obsolete stuff or companies that don't even exist any more. There is also the list at IANA (you need to scroll down to get to the multicast stuff), which I normally would think is preferable, but for some reason they don't have the assigned IPv6 multicast addresses listed.
Following the address fields is the type field. The type field is used to indicate what type of data is contained in the data field. By "type" of data, we mean the protocol (and not if we are sending and image or text). The most common protocols found in Ethernet frames are IP (version 4) and ARP, or, if you are in one of those places where IPv6 has made significant inroads, then IPv6 (which does not use ARP). The Ethertypes for these protocols are, respectively, 0800, 0806, and 86dd (all in hexadecimal). A list of Ethertypes can be found here, though the fact that 0806 is used for ARP is not obvious from the IEEE listing, but can be seen here. (There is a historical reason for this that has to do with a very old LAN called Chaosnet, invented by a company, now defunct, that was called Symbolics, which the IEEE lists as the owner of 0806, which was used by Chaosnet.)
And, since I'm talking about old LANs, and defunct companies, the Ethertype list includes many old protocols that are no longer in use. Since the primary use is for IP protocols, I'll also refer you to RFC 5342, "IANA Considerations and IETF Protocol Usage for IEEE 802 Parameters."
I don't think any elaboration is needed on what the data field is for. If the type field indicated that the data is IP, then an IP datagram would be contained in the data field, with a maximum length of 1500 bytes.
The last field is the CRC, or cyclic redundancy check, also called the Frame Check Sequence (FCS) field (which contains a CRC value). This 4-byte field provides error detection for the Ethernet frame. The CRC is calculated by the sender and then again by the receiver. If the value calculated by the receiver does not match what is in the CRC field, an error was detected and the frame is discarded. The CRC does not detect 100% of possible errors - theoretically, it is possible for there to be several bits switched in such a way that the sender's CRC (appended) and the receiver's CRC match, but this is highly unlikely. If a frame is discarded, since there is no acknowledgment (or negative acknowledgment), only a higher layer protocol (such as TCP) would concern itself with retransmission. The reader who is interested in the actual method for calculating the CRC is referred to the standard, p. 53 in the 2008 document (section 3.2.9).
Hands-on with Wireshark
At this point, let's take a look at the Ethernet frame format in some captured data. You might already have packet capture software installed on your computer - perhaps you installed it for another RAD University tutorial, such as DNS or SNMP. If not, I strongly recommend that you go to the effort to install a packet capture program, such as Wireshark (which I highly recommend and which is freeware). You can install the software as directed on the website. If you like computer networking and protocols, you'll find it helpful, not just for this tutorial.
Remember, we are discussing Ethernet frames, so that if you only have wireless LAN access, you can use Wireshark to examine the capture files that I provide. But it is always more fun if you can capture your own on Ethernet.
For my first example, I've got two frames of a rather antique protocol (from the early 1980s, though it is still in use). They are two DEC LAT frames (DEC=Digital Equipment Corporation; LAT=Local Area Transport). The packet capture was actually done on a large campus network with a wide variety of equipment, including some very ancient stuff (some of which I wonder if the network manager was even aware that it was still connected), so that I got a big assortment of protocols. I filtered out the two DEC LAT frames, and you can download the small pcap file, if you like, and open it in Wireshark. In Figure 10 you can see the details of one of the frames.
Figure 10: Ethernet Frame Containing DEC LAT Data
Let's first take a look at the source address. Because the Wireshark software contains a database of OUIs, it displays the beginning of the Ethernet address as "Digital". We can also see (in parenthesis) that the actual OUI value is 00:00:f8. If you check with the OUI list, you'll see that, indeed, that OUI is registered to Digital Equipment Corporation.
The destination is a mutlicast address that is registered to DEC for this protocol, as you can see on this list.
The Ethertype, x6004 is assigned to DEC LAT, which you can see here. And, in case you are curious about DEC LAT, it is a proprietary protocol that was defined for use on Ethernets, for communications between asynchronous terminals and terminal servers. The data field contains a short text message, which you can see.
You might wonder why, if IP is so dominant, I selected LAT as my first example. It is exactly for that reason. It is interesting to see stuff that we don't see all the time and important to know that there is other stuff out there besides IP. Sometimes, students that I teach don't understand why we need both MAC addresses and IP addresses - they identify their connection to an Ethernet with their connection to the Internet. When you understand that there could be other protocols running on your Ethernet, the distinction between the data link and the protocols that are encapsulated in the data link becomes clearer. DEC LAT is also interesting because it does not have a network layer, so it can't be routed, as IP can. Therefore, to connect multiple Ethernets with LAT traffic, bridges must be used.
Just so that you will see some Ethernet frames containing the types of traffic that you would more likely see on your own networks, we'll take a look at some frames that encapsulate IP and ARP, contained in this pcap file. And then we'll top off with a frame that contains IPv6 data. Take a look at Figure 11.
Figure 11: Ethernet Frame Containing ARP Data
The first packet in the file is an ARP packet, so you can see that the Ethertype is x0806, and since it is a query, it is sent to the Ethernet broadcast address. In Figure 12 below, we see the second packet, an OSPF "hello" message, which is sent to an IP multicast address, which in turn is transmitted at the data link (Ethernet) level to an Ethernet multicast address. And, because OSPF is sent over IP, we see that the Ethertype is x0800, IP's Ethertype.
Figure 12: Ethernet Frame Containing Multicast Data
The last packet in that file, shown in Figure 13 below, contains a unicast message (you haven't seen one yet!). It happens to be DNS, which runs over UDP, but what we are focusing on here are the Ethernet addresses - and the destination is unicast, and the Ethertype, which, again, is IP.
Figure 13: Ethernet Frame Containing Unicast Data
For our last trick, we'll take a look at a frame that encapsulates IPv6, contained in this pcap file, and displayed in Figure 14. Note that the Ethertype for IPv6 is 86dd
Figure 14: Ethernet Frame Containing IPv6 Data
In all of these examples, you can compare the Ethertypes, OUIs, multicast groups, etc. displayed by Wireshark with those on the various lists to which I provided links in the above paragraphs.
IEEE 802.3 Frame Format
In the first chapter in this Ethernet tutorial, I mentioned that the IEEE 802.3 frame format differs from the DIX frame format. Since IP uses the DIX format (which is what we saw above), and since the TCP/IP protocols are the overwhelmingly dominant protocols in use, almost all Ethernet traffic uses the DIX format. However, there are user protocols in use that use the IEEE format, as do spanning tree messages that are generated by bridges and switches. In addition, the IEEE 802.3 frame format contains the LLC (Logical Link Control) header, defined in the IEEE 802.2 standard. The LLC sub-layer is common to several other protocols, including IEEE 802.11, the wireless LAN standard, so that it is worth being familiar with this format.
Since the CRC is the same for both frame formats, we will focus on the differences in the header, as depicted in Figure 15.
Figure 15: DIX Ethernet Frame vs. IEEE 802.3 Frame
We see that instead of the two-octet type field, the 802.3 frame has a two-octet length field. The purpose of the length field is to specify the number of LLC data octets in the data field. If the value is less than the minimum required (remember why? To ensure collision detection by all stations, Ethernet has a minimum frame size), then padding will have to be added. When the destination station receives the frame, the way that the destination knows what is actual data and what is just meaningless padding is by looking at the length field.
So, the obvious question is - how does DIX Ethernet manage without a length field? All the protocols that use DIX Ethernet (which includes IP) for its data link encapsulation over Ethernet have their own length field. For example, the IP header has a field called Total Length, which indicates the total length of the encapsulated IP datagram. Therefore, the 802.3 length field is superfluous for those protocols.
The next question that should arise, though perhaps not as obvious, is: When a station receives an Ethernet frame, how does it know if the field after the source address is a type field or a length field. Can you think of a solution? If the value of the field is greater than 1500, it must be an Ethertype, because the length cannot be greater than 1500! Check it out - go back and take a look at the list of Ethertypes. So, you think you caught me there! Yes, there are actually Ethertypes whose values are less than 1500. These are actually a very few very old Ethertypes that conflict with the 802.3 lentth field range, such as the Xerox PUP protocol, with an Ethertype of 0200 (equal to 512 in decimal). Such conflicts are noted on this list.
If you've been paying attention, you should come up with another question. If 802.3 defines a length field where the (DIX) Ethernet type field is, then how does 802.3 specify the type of data (the next level protocol) that is encapsulated in the frame? That's the purpose of the next field, the DSAP (Destination Service Access Point) field, which is actually the first field in the LLC header. Actually, though, you can see that there are a pair of fields, DSAP and SSAP (Source Service Access Point), which IEEE considers LLC address fields. Just as the MAC layer destination and source addresses indicate the destination and source stations of an Ethernet frame, the DSAP and SSAP indicate the next level "addresses", i.e. protocol identifiers. Each one of these fields is 8 bits in length, and only 7 bits are used for the actual address, and one of those bits is used to indicate if the "address" is local or global (see Figure 16), limiting the number of possibilities for global protocol identifiers to 64 (26).
Figure 16: SAP Field
The weirdest part of the DSAP and SSAP is that when IEEE conceived of this, there were these ideas that (a) a message might be destined for a group of next layer protocols, and (b) the source protocol might not be the same as the destination protocol, hence two fields! In retrospect, what a waste of space! If there were only one field that was 16 bits, one of which could be used as a local/global bit, instead of two that are 8 bits each (with one bit in each one defined for unlikely purposes and one bit in each for a local/global bit), there would not have been need for even more overhead, which we shall see in the next section on the SNAP header.
But, as I sometimes say, "history happens" and the LLC is as it is. Each SAP field is made up of two components. In the DSAP address field, the components are an address type designation bit, and seven bits of the actual address. When the address type designation bit is set to 0, it indicates that the actual address is an individual address. When the address type designation bit is set to 1, it indicates that the DSAP actual address is a group address - used to send a message, after a destination station receives it, to be passed on to a group of protocols at the next level. Think of sending a message to a host that will then pass it to IP and to Appletalk to parse. I said it is weird.
In the SSAP address field, the components are the command/response identifier bit, and seven bits for the actual address. The actual address in the SSAP field is always an individual address. Right, we really couldn't conceive of a group of different protocols cooperating to send one message. I can't think of an example of common use of the command/response bit.
So, for the purpose of fulfilling the task of the type field in the (DIX) Ethernet frame, we have 6 bits of the DSAP field for global protocol types. Because of the limited number of values that can be generated by these 6 bits, the IEEE was quite restrictive in who could get one. The criteria were: the protocol needs to be a standard published by an internationally recognized standards organization, the standard can only be changed as a result of a public review process, and the standard has a potentially large field of application. Several protocols that were very popular at the time did not cut it and did not receive a SAP value. IP actually managed to get one, but to operate, IP needs two - one for IP and one for ARP! So the IP SAP is never used. (Theoretically, IPv6, which does not have ARP could have managed with one LLC number, but it is not done.)
We'll get back to how IPv4 and IPv6 are encapsulated in LLC (for protocols that don't have another option), but before we do, I'll explain the control field, an 8-bit field, in the LLC header. The control field is also one of those fields that must have been a good idea at the time, but has little application. The control field indicates whether communication is connectionless (Type 1), or connection-oriented (Type 2), which is also reliable (i.e., there is an acknowledgment), or reliable connectionless (Type 3), which means that there is an acknowledgment. Ethernet as we know it (DIX or 802.3) is connectionless and unreliable. There is no connection procedure before sending data or acknowledgment for received data on Ethernet, no matter which frame format is used. Any such features are provided by a higher layer, such as TCP. Other bits in the field indicate various functions of the frame, all of which were inherited from HDLC. The interested reader is referred to the 802.2 standards document. Generally, for the most likely type of traffic you'll see, the value of the control field is 0x03 (and that is true for those protocols that require IP or IPv6 to use an LLC header, such as IPv6 over Token Ring).
SNAP Header
Now you'll get to see why IP is encapsulated in the classical (DIX) Ethernet frame rather than the 802.3 frame. I stated in the previous section that not all protocols received a SAP number (and that IP's is useless). IEEE did provide for protocols that do not get a SAP number by defining a special SAP number called the SNAP SAP (yes, I know, ugh!). SNAP stands for Sub-Network Access Point, and the value of the SNAP SAP is AA. When the DSAP (and SSAP) is set to AA, it means that following the control field, there is a special, additional header, called the SNAP header, as shown in Figure 17 (and compared to the 802.3 header that we saw until now).
Figure 17: SNAP Header
Following the DSAP and SSAP, which are each set to AA, and the control field, there is an OUI (Organizationally Unique Identifier), also called the Vendor Code. This is intended to represent the organization responsible for the protocol, whose type will follow. For IP, the OUI that is used is 0x00-00-00 (yes, three bytes of all zero). And then, finally, the type field, which, can you believe, is the same as the Ethertype that we have come to know and love from the classic Ethernet frame. So, for IP, it is 0x0806 and for IPv6 0x86DD.
Figure 18 displays the contents of an 802.3 frame that is contained in this pcap file. Notice that this frame has a SNAP header and that the DSAP and SSAP are both equal to AA. The value of control field is 0x03, the OUI is 00-00-00, and the Ethertype is 0x8137, which is for a proprietary protocol (Novell's IPX), which was not granted a global SAP number by the IEEE. You can check the Ethertype on the list of Ethertypes.
Figure 18: 802.3 with a SNAP Header
It should be pretty obvious why IP uses the classic Ethernet format, when running over Ethernet. Instead of one 2-byte type field, to get the same information, we need an additional 8 bytes! (two for the length, which is unnecessary, one each for DSAP and SSAP, one for control, three for the OUI - that's eight!) However, there are several protocols for which IP has no choice, and this is one of the reasons that it is valuable to know about the SNAP header.
