Scott Parks wrote in a message to Mike Bilow:
 MB> ...it is much better to run IPX on Ethernet_802.2 properly
 MB> and discard the Ethernet_802.3 pseudo-frame type, especially
 MB> when you are running multiple protocols (such as TCP/IP) in
 MB> the network.
 SP> You get a chance to go deeper ;)
 SP> I inherited this network and tend to go with what works.  We
 SP> have had IPX and IP since I've been here.  Did not the
 SP> default frame type change between 3.x and 4.x .... and if so
 SP> why?  Remember we are running 3.11 so is there a difference
 SP> on what works best?  
 SP> I guess I don't understand "psuedo" in this situation.
Actually, the default frame type changed between 3.11 and 3.12.  This 
requires some history.
IEEE is an organization that, among other things, writes standards documents 
which define networking over Ethernet.  IEEE 802.3 is a hardware standard, 
and IEEE 802.2 is a software standard.  Put simply, IEEE 802.2 defines the 
logical organization of the physical frames defined by IEEE 802.3.
Now, when Novell originally started in the networking business, they made 
some bad decisions.  In particular, they assumed that you would never run 
anything except Novell NetWare on your Ethernet, and they decided to trash 
many years of experience with more sophisticated protocols such as TCP/IP.  
Above all, Novell was anxious not to replicate the staggering complexity of 
something like SNA, which was a reasonable concern for a company whose 
business at that time was making little TSRs that ran on XT network clients.
While small and simple is good, Novell went too far.  IPX was originally a 
kludge that just dumped raw frames onto the Ethernet wire and used raw 
hardware (MAC) addresses as network addresses.  Novell completely ignored the 
IEEE software standard, which caused major headaches when running IPX and 
non-IPX protocols on the same Ethernet wire.  Somewhat ingenuously, Novell 
calls this absence of a protocol the "Ethernet 802.3" frame type.
Had Novell followed IEEE 802.2, they would have organized their frames in a 
standard way containing a registered protocol identifier.  This allows all 
sorts of different protocols to coexist peacefully, since they each use a 
unique protocol identifier number.  Any protocol stack can look at any IEEE 
802.2 frame and immediately recognize whether the protocol number is its own, 
correctly deciding to process or ignore the frame as appropriate.
The entire rest of the world uses Ethernet 802.2 frame type.  TCP/IP, which 
antedates the IEEE standard, uses the Ethernet II frame type, but it has a 
special exception written directly into the IEEE 802.2 standard that was 
crafted to guarantee backward compatibility.  The Ethernet SNAP frame type, 
which you may see occasionally in connection with IBM SNA, is actually just a 
fully compliant but yet further subdivided Ethernet 802.2 frame.
By sheer chance, Novell IPX frames using the Ethernet 802.3 "frame type" just 
happen to have two bytes set in a certain pattern that is illegal under IEEE 
802.2, and this allows software to recognize these as IPX frames.  However, 
that sort of informal practice is dangerous, since software which doesn't 
understand about this de facto screw up can get confused or even crash.  This 
is particularly critical where one protocol is encapsulated into another and 
must be unencapsulated on the receiving end, such as when IP tunneling is 
used to carry IPX frames across the Internet.
Eventually, Novell conceded the blindingly obvious and formally recommended 
that IPX usage be migrated onto the real Ethernet 802.2 frame type, using the 
legitimate protocol identifier number assigned to it.  So great a mea culpa 
is rare among large corporations, and Novell deserves credit for doing it.  
Despite the best efforts of Novell, however, many network managers resisted 
the change, usually because they didn't understand the significance of it, 
didn't want to go around changing the software on every network client, and 
didn't want to mess with anything that was actually working.
This reluctance to change on the part of real network managers is now 
starting to blow up in their faces.  Novell Client 32, for example, supports 
binding IPX to more than one frame type (each of which corresponds, in turn, 
to a "logical board" in the ODI system).  Windows 95 will behave very 
strangely and unpredictably if you don't enforce a consistent frame type for 
IPX across the network, and the clearly correct approach is to unbind IPX 
from the Ethernet 802.3 "frame type" at the server, forcing all clients onto 
the Ethernet 802.2 frame type.  For example, DOS network applications -- such 
as MAP and LOGIN -- will use the first logical board bound to IPX when run 
under Windows 95, and it is a coin flip whether this is Ethernet 802.2 or 
Ethernet 802.3 on any particular client machine.  I have personally and 
repeatedly locked up Windows 95 to the point of having to hit the reset 
switch because of this.
 
-- Mike
--- 
---------------