My question pertains to DIX (Ethernet II) and Ethernet: what is the link layer difference, if any? I don't see the link layer in the standard lists, but when doing, for instance, a pcap capture I see that wireshark will frame them differently (I'm not going to post pcap, but I'm sure the standards are posted). source: http://www.tcpdump.org/linktypes.html
The Ethernet header has, in order:
In the original DEC/Intel/Xerox ("DIX") Ethernet specification, the 2-byte field was specified as a type field, giving an Ethernet type value specifying what protocol was running atop Ethernet; for example, a value of hex 0800 is used for IPv4.
In the original IEEE 802.3 specification, however, it was specified as a length field, giving the length of the payload following the Ethernet header. (Ethernet frames less than 64 octets, including the FCS, are padded to 64 octets; the length field allows the padding to be ignored. Some protocols, such as IPv4 and IPv6, include their own length field, so the padding can be ignored even without the Ethernet length field.)
If the 2-octet field isn't a type field, that leaves no mechanism for indicating what protocol is running atop Ethernet. The IEEE specified the IEEE 802.2 header, which follows the link-layer header in IEEE 802.x LANS (802.11, 802.5 Token Ring, 802.3 Ethernet, etc.), as well as FDDI; it includes 1-octet Destination Service Access Point (DSAP) and Source Service Access Point (SSAP) fields that can be used to specify the protocol running atop Ethernet.
So the difference between "DIX" Ethernet and "IEEE 802.3" Ethernet was, originally, that, in DIX Ethernet, the 2-octet field was a type field and there was no IEEE 802.2 header following the Ethernet header, whereas in IEEE 802.3 Ethernet, the 2-octet field was a length field and there was an IEEE 802.2 header following the Ethernet header.
The maximum length of an Ethernet frame is 1518 octets, including the 14-octet Ethernet header and the 4-octet FCS, so the maximum length of the Ethernet payload is 1518-(14+4) = 1500 octets. This means that the maximum value of an Ethernet length field is 1500.
The minimum value for an Ethernet type is hex 0600, or 1536. If the 2-octet field's value is between 0 and 1500, the field is a length field, and if it's greater than 1536, it's a type field. (If it's between 1501 and 1535, it's an invalid Ethernet frame.) This allowed DIX and IEEE 802.3 frames to be used on the same Ethernet segment.
IEEE Std 802.3x-1997 changed IEEE 802.3 so that it specified that the 2-octet field could either be a type field or a length field, and all subsequent versions of IEEE 802.3 have included that, so, starting at some point in 1997, DIX frames were also valid IEEE 802.3 frames.
Novell also ran their protocols directly atop IEEE 802.3, with no 802.2 header; their frames began with two hex FF octets, which meant that they would look like frames with the DSAP and SSAP values both set to hex FF. Hex FF is not a valid SSAP, as it has the "group address" bit set, so Novell frames without 802.2 ("Ethernet 802.3" frames) and 802.3 frames with an 802.2 header ("Ethernet 802.2" frames) can be distinguished from one another.
The DSAP and SSAP fields aren't sufficient to handle all protocol types, so the Subnetwork Access Protocol (SNAP) was devised. If the DSAP and SSAP in the 802.2 header are both hex AA, then the 802.2 header is followed by a SNAP header, which has a 3-octet Organizationally Unique Identifier (OUI) followed by a 2-octet Protocol ID (PID). The OUI is a number given out to organizations by the IEEE; it's used as the first 3 octets of MAC (Ethernet, 802.11, Token Ring, FDDI) addresses assigned to that organization (an organization can have multiple OUIs, so if they run out of MAC addresses in one OUI's range, they can assign more). The PID's interpretation is dependent on the OUI value. An OUI of 0 means that the PID is an Ethernet type value; other OUIs mean that it's a value assigned by the organization to whom that OUI belongs.
IPv4 and IPv6 packets sent over 802.x networks other than Ethernet, and over FDDI, have the link-layer header, the 802.2 header with the DSAP and SSAP both being AA, and a SNAP header with an OUI of 0 and an Ethernet type of hex 0800 (IPv4) or hex 86dd (IPv6). Over Ethernet, they'll have 0800 or 86dd in the type/length field, and no 802.2 header.
For more information, and some history about why all those frame types exist, see Don Provan's Ethernet Frame Types: Provan's Definitive Answer (archived at Wayback Machine).
The link-layer header types in pcap and pcapng files, as listed in the tcpdump.org link-layer header types page, correspond to formats for the octets that appear at the beginning of the packet data. LINKTYPE_ETHERNET/DLT_EN10MB, as that page says, corresponds to "IEEE 802.3 Ethernet", with a 6-octet destination address, a 6-octet source address, and a 2-byte type/length field, in order, so packets with a type field and packets with a length field are both covered by LINKTYPE_ETHERNET. They are not distinguished by the link-layer header type value; they are distinguished by the range in which the type/length field value appears (valid length field, valid type field, invalid field).
(And, yes, perhaps Wireshark shouldn't make as big a distinction between Ethernet frames with a type field and Ethernet frames with a length field; it should perhaps show them both as Ethernet frames, and show the 2-octet field as a type field if it's a type, a length field if it's a length, and as a "none of the above" field if it's invalid.)