Ethernet Framing

don provan

unread,

Sep 17, 1993, 3:09:26 PM9/17/93

to

Ethernet Frame Types: Provan's Definitive Answer:

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:

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:

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:

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.

=====================================================================

don provan
do...@novell.com

don provan

unread,

Sep 17, 1993, 3:12:08 PM9/17/93

to

Ethernet Frame Types: Provan's Definitive Answer:

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
adminitrator, 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.

don provan
do...@novell.com

don provan

unread,

Sep 17, 1993, 3:14:01 PM9/17/93

to

Ethernet Frame Types: Provan's Definitive Answer:

Which Ethernet Frame Type Should You 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 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.)

don provan
do...@novell.com

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. -dp

don provan

unread,

Sep 17, 1993, 3:06:54 PM9/17/93

to

Ethernet Frame Types: Provan's Definitive Answer:

Introduction
------------

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?

Rather than try to answer all four questions in the same message,
I've elected to post five different messages: this introduction, plus
one message to answer each of the four questions. For ever after, i
hereby appoint Joe Doupnik to see to the posting (or mailing, should
the consciousness of the mailing list be raised to the point where
posting becomes redundant) of the appropriate answer whenever this
question comes up. I also suggest that these answer be added to the
FAQ, and i'll make the entire pamphlet available for anonymous FTP on
sjf-lwp.sjf.novell.com in odi/eframe.txt.

Or i may just publish it and live in opulence on the royalties.

don provan
do...@novell.com

don provan

unread,

Sep 17, 1993, 3:32:04 PM9/17/93

to

Dear Friends,

Some of you might be wondering what prompted me to post my recent (or
future, depending on how time runs in your news service) opus on
Ethernet frame types. Well, yes, continual nagging by y'all out there
had something to do with it, but primarily it was the last major
contribution i needed to make to these forums before i dropped off
line. A sharp increase in my responsibilities here at Novell make it
impossible for me to continue participating in these lists. In fact,
i haven't had time to read them for a week or two already. With
regret i will be hitting the old unsubscribe key as soon as i've
finished posting this last note.

I'm sure y'all'll be able to carry on without me. Rest assured that
i'll be busy working under the covers to make sure that Novell
continues to supply you with the best products possible. Au revoir.

don provan
do...@novell.com

don provan

unread,

Sep 17, 1993, 3:10:47 PM9/17/93

to

Ethernet Frame Types: Provan's Definitive Answer:

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.

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".

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.

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.

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 descriminating 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 a 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.

Why does IPX run on all four frame types?
-----------------------------------------

Good question.

don provan
do...@novell.com

ag...@ucs.cam.ac.uk

unread,

Sep 18, 1993, 12:29:18 PM9/18/93

to

In article <1993Sep17.1...@novell.com> do...@novell.com (don provan) writes:
>I also suggest that these answer be added to the
>FAQ, and i'll make the entire pamphlet available for anonymous FTP on
>sjf-lwp.sjf.novell.com in odi/eframe.txt.

I'm sure many people will appreciate the effort that has been put into
this but if it is going to go into the FAQ I think it ought to be made
clear it is a personal view. Apart from one or two purely factual
inaccuracies it makes a lot of claims about IEEE vs. DIX which aren't
really backed up. A proper list of which protocols actually do use
DIX, 802.2 or SNAP would be interesting, but a highly selective one is
not, and proves nothing.

In particular there were several users of non-SNAP 802.2 before Novell,
apart from OSI. SNA, X.25, MMS, RPL to name but four, as well as
low-level protocols like the bridge spanning tree protocol which you
may have running on _your_ LAN whether you like it or not. It also
dismisses IEEE's technical improvements such as the separation of
media-dependent and independent parts. (DIX is unique to Ethernet;
802.2 is exactly the same frame as you get on FDDI and IBM token ring.)
Even Novell are using this separation of layers in their new LAN
driver architecture. Maybe that will even mean the 802.2 frame
processing is more optimised than DIX frames, since the 802.2 module
is a more general piece!

PCNews user

unread,

Sep 18, 1993, 8:25:50 PM9/18/93

to

ooooooohhhhhhhhh..... I hope you may find time to help from
home ?! I'm at home now too, remote control...

Larry Bradley

unread,

Sep 21, 1993, 5:34:11 AM9/21/93

to

Don, on behalf of all of us who have benefitted from your words over the
past couple of years, a hearty "Thank You", and best wishes to you with your
new respsonsibilities at Novell.

Larry

Jane Hesler

unread,

Sep 28, 1993, 3:24:30 PM9/28/93

to

I hope others from Novell are still reading this news group.
Novell needs to keep in touch with the people in the trenches.
Feed back from users is essential for Novell to

"to supply you with the best products possible."

In article <1993Sep17.1...@novell.com>, do...@novell.com (don provan) wri
tes:

--

Jane Hesler Internet: hes...@gems.vcu.edu
Virginia Commonwealth University Bitnet: hes...@vcuvax.bitnet
Box 16 Fax: 804-786-9807
Richmond, VA 23298-0016 Phone: 804-786-9843