I'm often stopped on the street, metaphorically speaking, and asked, "Hey, Don, what *is* it with these Ethernet frame types." I've determined that the inquisitor generally wants the answer to one of four questions, which I list here in rough order of increasing inflamedness:
(1) Physically, what do the four Ethernet frame types look like?
(2) Politically, where do the four Ethernet frame types come from?
(Or, put more simply, "Why are there four?")
(3) If Ethernet_802.3 is so Yucky, should I stop using it?
(4) Which Ethernet frame type should I use for IPX?
L.2 The Physical Structure of the Four Ethernet Frame Types
Here is the physical appearance of the four Ethernet frame types, listed in rough order of creation. I will ignore the purely electronic aspects of the frame, including start bits and Frame Check Sequence. Those are required by the physical hardware and are, consequently, uniform for all four frame types.
Novell Frame Type Designation: Ethernet_II Common name: Ethernet Layout:6 bytes 6 bytes 2 bytes Up to 1500 bytes +-------------+-------------+-------------+-------------------------+ | Destination | Source | E-type | Network Protocol Packet | | MAC Address | MAC Address | (IPX: 8137) | | +-------------+-------------+-------------+-------------------------+
Comments: 1. Used for TCP/IP as well as many other protocols. 2. Most common frame type in general, although Ethernet_802.3 might possibly carry more packets world wide.
Novell Frame Type Designation: Ethernet_802.3 Common name: "Raw" 802.3 Layout:
6 bytes 6 bytes 2 bytes Up to 1500 bytes +-------------+-------------+--------------+------------------------+ | Destination | Source | Total packet | IPX Packet | | MAC Address | MAC Address | length | first two bytes: FF,FF | +-------------+-------------+--------------+------------------------+
Comments: 1. No protocol ID: Can only carry IPX packets. 2. Distinguishable from Ethernet_802.2 only because the first two bytes of all IPX packets carried on Ethernet_802.3 must be all ones, which makes no sense in Ethernet_802.2. 3. The default frame type for NetWare software until NetWare v4.0 was released.
Novell Frame Type Designation: Ethernet_802.2 Common Name: 802.3 (the 802.2 header is implied by the 802.3 standard). Also Known As: 802.3/802.2, to distinguish from "raw" 802.3 Layout:
6 bytes 6 bytes 2 bytes 1 byte 1 byte 1 byte Up to 1497 bytes +------+------+--------+------+------+--------+---------------------+ | Dest | Src | length | DSAP | SSAP | Control| Network Packet | | Addr | Addr | | (E0) | (E0) | (03) | | +------+------+--------+------+------+--------+---------------------+
Comments: 1. Used for OSI packets on 802.3 networks. 2. Numbers in parentheses are the values used by IPX. 3. The default frame type for the NetWare v4.0 release.
Novell Frame Type Designation: Ethernet_SNAP Common name: 802.3/SNAP or 802.3/802.2/SNAP Layout:
6 b 6 b 2 b 1 byte 1 byte 1 byte 5 bytes Up to 1492 bytes +----+----+---+------+------+------+---------------+----------------+ |Dst |Src |len| DSAP | SSAP | Ctrl | SNAP ID | Network Packet | |Addr|Addr| | 0xAA | 0xAA | 0x03 | (0,0,0,81,37) | | +----+----+---+------+------+------+---------------+----------------+
Comments: 1. Extension to 802.2, indicated by SAP value of hex AA. 2. Number in parentheses is the value used for IPX. 3. Used by AppleTalk. Almost never used for IPX.
L.3 The Political Origin of the Four Ethernet Frame Types
Many people want to know why there are four Ethernet frame types. Each one has a story, as I'll explain below.
L.3.1 Where did Ethernet_II come from?
The frame type NetWare software calls Ethernet_II is basically the original Ethernet frame type. There were actually two earlier Ethernet standards before the final one we know today. The first was strictly experimental and ran at 3 megabit. The second was the 10 megabit Ethernet we've come to know and love, but it had a few kinks which were quickly ironed out in the DIX Ethernet standard (named for DEC, Intel, and Xerox, the three companies that developed it). Because of the earlier standard, the "new" one was often refered to as "Ethernet II", although the actual packet formats were the same for both standards. (The DIX standard had slightly different hardware signaling specifications.) These days, the history has been long since forgotten and no hardware has survived from the pre-DIX Ethernet days, so the currrent standard is now commonly known as simply "Ethernet".
L.3.2 Where did Ethernet_802.2 come from?
With Ethernet happily deployed around the world, some dim bulb decided to have it blessed by a standards body. The body was IEEE. The result was the 802.3 specification. IEEE just couldn't resist changing the Ethernet framing in a pointless, yet significant way. They eliminated the two byte protocol ID (known in Ethernet as the "Ethernet Type" or "E-type") and replaced it with a two byte length. The protocol ID was then carried within the 802.3 packet in an 802.2 header, keeping in accordance with the overall IEEE 802 plan.
The 802.2 header made 802.3 consistent with the other 802 physical layer protocols. This was intended to allow easy use of these datalink layers by the ill-fated OSI protocol suite. Until NetWare v4.0 shipped with Ethernet_802.2 as the default for Ethernet drivers, OSI was the only significant use of the 802.3/802.2 protocol (except for a few uses of the SNAP extension to 802.2, which in Novell drivers is a different frame type: Ethernet_SNAP).
Ethernet_802.2 packets are distinquished from Ethernet packets by having a packet length of 1500 bytes or less. Ethernet protocol IDs are all larger than 1500 decimal.
L.3.3 Where did Ethernet_802.3 come from?
Ethernet_802.3 came from Novell. At some point in the development of 802.3, someone at Novell got a copy of the 802.3 specification. I wasn't around at the time, so I don't know for sure what happened, but apparently it didn't occur to anyone that a legitimate datalink protocol would simply *have* to carry a network layer protocol identification. (Without a protocol ID, the datalink protocol could only be used for a single protocol, which isn't very practical.)
Anyway, to make a long story short, some Novell engineer implemented 802.3, but *without* the required 802.2 header. (Novell apologists claim that at some point in the early days of 802.3, the 802.2 header wasn't required. I'll believe that the requirement for 802.2 might not have been clearly spelled out at some point, but I cannot believe that anyone on the 802.3 committee thought 802.3 didn't need a protocol descriminator, so I'm sure the intention was always for 802.2 to be required.) Instead of an 802.2 header, in the Ethernet_802.3 frame IPX simply sits right in the 802.3 packet as the only possible protocol.
Now normally you might think that having two protocols, IPX and 802.2, both riding in the same place in the same type of frames would cause a problem. Indeed, there have been isolated cases over the years of nodes expecting 802.2 being confused by arriving IPX packets and vice versa. But by a remarkable stroke of serendipity, IPX packets, which until just recently always started with two bytes of all ones, look ridiculous to properly implemented 802.2 code. (And, on the other hand, 802.2 packets never start with two bytes of all ones, which makes them invalid as IPX packets transmitted in Ethernet_802.3 frames.) This has made the number of problems quite limited, and such bugs in the packet handling code were generally fixed posthaste.
L.3.4 Where did Ethernet_SNAP come from?
802.2, being three bytes long, makes the network layer packet badly aligned in an 802.3 packet. In addition, only seven bits are available in 802.2 for discriminating between different protocols, so there can only be 128 different protocols on an 802.2 network.
The solution to these problems, driven by the TCP/IP community which -- guess what? -- likes to have its packets aligned and requires several protocols, was SNAP (which stands for something, I just can never remember what)*, which in Novell LAN drivers is the frame type Ethernet_SNAP. SNAP uses a single 802.2 protocol ID (hex AA) to indicate a SNAP packet. The SNAP packet, carried inside the 802.2 packet, has a five byte header followed by the network layer protocol. The five byte header is simply a five byte protocol ID. The first three bytes of the protocol ID are an Organizational Unit Identifier (or OUI) identifying the authority assigning the protocol ID. The last two bytes are the protocol ID according to that authority.
This sounds a little complicated, but in practice the three byte OUI is always zero and the last two bytes are always the Ethernet Type code assigned to the protocol for use on standard Ethernet. (Well, ok, there is one exception: AppleTalk, for reasons I cannot fathom, uses some other OUI (presumably Apple's), but still uses the Ethernet Type as the last two bytes. The punch line is that AppleTalk's auxilliary protocol, AARP, uses an OUI of zero. Go figure.) In other words, when SNAP is used, it typically ends up being eight extra bytes of datalink header just to get back to the information that's normally carried in the simple Ethernet packet.
Note: The RFCs have it that the acronym SNAP stands for SubNet Access Point, but the word "subnet" muddies the waters.
L.3.5 Why does IPX run on all four frame types?
Good question.
L.4 Should You Use Ethernet_802.3?
You probably know by now that since the frame type Ethernet_802.3 does not carry the required 802.2 header, it is not conformant to the official 802.3 specification. You may also have heard about problems on networks using Ethernet_802.3 frames. As a conscientious network administrator, this may cause you to worry about using the Ethernet_802.3 frame type on your network. Here are some guidelines for deciding whether to switch away from Ethernet_802.3.
First of all, if you are installing a *new* network, then *don't* use Ethernet_802.3. One thing's for sure: Ethernet_802.3 is obsolete. New networks should use a more current frame type such as Ethernet_II.
So the only real question is whether you should convert an existing Ethernet_802.3 network to some other frame type.
The first observation is that Ethernet_802.3 isn't generally dangerous. The problems that have occurred because of Ethernet_802.3 frames are few and far between, and generally involve older hardware or software. If you haven't already seen any such problems, then you probably never will. So normally there's no risk to keeping Ethernet_802.3 as a existing network's frame type. In particular, if your Ethernet_802.3 is fairly static and you do not plan any major upgrades or additions to it, then you can continue with Ethernet_802.3 indefinitely without concern.
On the other hand, Ethernet_802.3 is an obsolete frame type, as I say. So if you find a convenient opportunity, you may want to switch a network away from it. For example, if you decide to upgrade all of your client nodes from older software to an ODI driver or the VLM client, that might be a good time to also switch to Ethernet_II since you're already making modifications on every node.
One consideration that may be important to you is that IPX packets with checksums cannot be transmitted on Ethernet_802.3 networks. In order to take advantage of the data integrity provided by the IPX checksum feature of the newer NetWare releases, you'll have to upgrade your Ethernet_802.3 networks to Ethernet_II or some other Ethernet frame type.
Note that a single Ethernet can carry both Ethernet_802.3 and Ethernet_II traffic at the same time. Novell software treats the two frame types as entirely different logical networks even though they are being transmitted and received on the same NIC. A NetWare v3.x or v4.x server with its IPX bound to two logical boards running the two frame types will function as an IPX router between the two "networks". (Notice that there *are* two networks, so they need two *different* network numbers.) This allows you to upgrade Ethernet_802.3 nodes one by one to Ethernet_II. The NetWare router will forward packets from one "network" to the other, allowing the upgraded nodes to continue talking to the older nodes and vice versa.
L.4.1 What frame type Joe D. uses
My place did that years and years ago, and it is not a big a problem as it might seem. To change, schedule a weekday at 08:00-09:00 when the net will be down and yet all the responsible people will be present to control their boxes. The afternoon before "the day" change all server autoexec.ncf files in preparation for a reboot the following morning. Have area people update user net.cfg files for that same reboot time. Tell users about the affair, and about the net.cfg modification. At 08:00 shut down servers and printer boxes and whatnot. Wait for quiet wires (to prevent those "server X claims network YYY is ZZZ" mistakes. Then start firing up servers, then the tiny boxes, then the users. Real elapsed time is maybe 15 minutes, leaving 45 more to chase down boxed under desks, in forgotten closets, etc.
My place is 20K students, 50+ NW servers on the backbone, nearly uncounted small boxes. We've done this massive update thrice: once to kill all Ethernet_802.3 traffic which was zapping machines and causing server crashes, a second case to regularize IPX names and numbers (the Utah Standard) and again to regularize the Appletalk mess. All occassions were trouble free, created only positive comments from users, and the place was better off for it.
We are a very tolerant networking outfit. But we simply forbid Ethernet_802.3 packets on backbones. There is no reason at all to use it. We also tell system managers to never use Ethernet_802.2 because it was crippled at birth and has no benefit in its favor other than to support some RPL situations. The result is greater functionality for everyone at no cost, and that's the bottom line.
[Thx Joe D.]
L.5 Which Ethernet frame type should I use for IPX?
One thing we can all agree on: you should *not* use Ethernet_802.3 unless you are connecting an installed network that uses it. Refer to my other note, "Should You Use Ethernet_802.3?", for a complete discussion of Ethernet_802.3. For our purposes here, I assume Ethernet_802.3 isn't being considered.
Novell does not, at least to my knowledge, explicitly recommend any one Ethernet frame type for carrying IPX traffic, although perhaps the default frame type of Ethernet_802.2 on the v4.0 LAN drivers might provide a clue. My PERSONAL recommendation, however, is, "When given a choice, run IPX on Ethernets exclusively with the Ethernet_II frame type."
While there are a couple of technical arguments I can make in support of Ethernet_II, they really aren't important enough to mention. (But I'm always asked what they are, so I'll explain them in a moment.) The real reason I recommend Ethernet_II is that it's the true Ethernet standard. With only a couple of exceptions, every significant protocol uses Ethernet_II instead of either Ethernet_802.2 or Ethernet_SNAP.
[The exceptions? OSI runs on Ethernet_802.2, and the "new" AppleTalk runs on Ethernet_SNAP, although the old AppleTalk runs on Ethernet_II. (I quote "new" because the later version of AppleTalk is actually fairly well established; it's basically just what you'd think of as AppleTalk. Pure "old" AppleTalk networks are rather rare these days.)]
The practical effect of Ethernet being the principle framing standard is that you are often using Ethernet_II framing already for some other protocol. If you're running any other protocol (other than OSI), using Ethernet_802.2 for IPX will mean having one more frame type to worry about on that NIC. For example, if you're using TCP/IP on a NetWare v3.11 server, the Ethernet_II frame type is already loaded for IP. If you also run IPX over Ethernet_II instead of Ethernet_802.2, you won't have to reload the LAN driver for a second frame type.
Another practical consideration is old NetWare software. Pre-ODI clients and 2.x servers can be switched to Ethernet_II framing using an old, widely available, utility: ECONFIG.EXE. Pre-ODI clients cannot talk Ethernet_802.2. I've heard rumors that some 2.x servers can be configured to use Ethernet_802.2, but I have no idea how that's done or where you get the software components needed to do it.
I rule out Ethernet_SNAP simply because IPX has never been normally run on that frame type. There's no significant technical advantage for IPX between Ethernet_II and Ethernet_SNAP, but Ethernet_II is by far the more common of the two, particularly for IPX.
One thing's for certain: no matter which frame type you decide to use, SPECIFY IT in your configuration files. Do *NOT* let the LAN driver use the "default" frame type. The default can change from version to version of the LAN drivers, but you don't want any given node to change its frame type just because a driver was upgraded. To ensure that doesn't happen, tell the LAN driver explicitly which frame type to use, even if you think the frame type you've selected is the default. (This is actually general advice: when configuring *any* software, only allow the software to use default values when you really don't care what the value is. Since the wrong frame type would break communications, you really *do* care exactly which frame you're using, so specify it.)
P.S. No, I didn't forget. The first minor technical advantage of Ethernet_II is that in it the IPX packet is aligned to the proper word boundary. The poor alignment of Ethernet_802.2 will cause a slight performance penalty in some cases, although I've seen nothing to indicate the performance penalty would ever be significant...or even measurable, for that matter.
The second is that in Ethernet_II, the hex E-type 8137 is officially assigned to IPX by IEEE. The Ethernet_802.2 SAP which IPX uses (hex E0) is *not* officially assigned to IPX. E0 is in the range of SAPs which are reserved for local definition. This means that there's no official restriction against some other network protocol using a SAP of E0, although in practice it is extremely unlikely anyone would ever do such a thing.
[Thanks to Don Provan for this info]
Some added reading material about the subject from the Internet RFC archives (anonymous ftp to nic.ddn.mil or mirrors thereof):
1. RFC-1011, "Official Internet Protocols" by Reynolds and Postel.
2. RFC-1060, "Assigned Numbers" by Reynolds and Postel.
3. RFC-1042, "A Standard for the Transmission of IP Datagrams over
IEEE 802 Networks" by Reynolds and Postel.
[Thx Joe D.]
RFC-1011 Official Internet... superceded by RFC-1600 same name RFC-1060 Assigned numbers superceded by RFC-1700 same name[Thanks to Henrik Olsen for this additional info]
A free booklet is available from Lantronic (1-800-422-7055) called "Ethernet Tutorial and Product Guide".
[Thx L.C.H.]