Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!ftp!jbvb
From: jbvb@ftp.COM (James Van Bokkelen)
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: Re: Packet Driver Spec. and Novell.
Summary: Did I describe "ISO-compatible" Novell?
Message-ID: <379@ftp.COM>
Date: 15 Oct 88 21:59:57 GMT
References: <8809301744.aa14758@Louie.UDEL.EDU> <8810061458.AA11891@vax.ftp.com> <293@rsp.UUCP>
Organization: FTP Software Inc., Cambridge, MA
Lines: 35

In article <293@rsp.UUCP>, tom@rsp.UUCP (Thomas Ruf) writes:
# ...
# 1) What Novell calls "IEEE" :
#
#    +dest|source|length|ipx-stuff+
#
#    i.e., just use the 802.3-like length field WITHOUT any additional
#    link layer. Novell also insists that the length field has to be even.
#    Most Novell ethernet drivers (3Com, Novell Ethernet) use this format
#    as default.

# 2.) Ethernet style :
#    NetWare 2.1 added a "new" encapsulation method, the one we've all
#    been waiting for : standard ethernet type codes.  Novell was assigned
#    typecode 0x8137.  I assume they were forced to go this way with the
#    introduction of NetWare/VMS.
# ...
# Thomas

Another person I heard from via direct mail also suspected that DEC's XE
driver forced them to use a standard encapsulation...

Two points: 1) I have heard references to a Novell Ethernet encapsulation
referred to as "ISO-compatible", and 2) I have seen many dumps of Novell
Ethernet packets with the following headers:

	dest|source|length|0x11 0x11| 0xFF 0xFF

The FF FF and the data that follows can be understood pretty well if you treat
it as an XNS packet with no end-to-end checksum.  Does "ISO-compatible" refer
to this kind of headers, and does it constitute yet a third Novell
encapsulation?

James VanBokkelen
FTP Software Inc.