🚀 go-pugleaf

+---------------
| Thanks to the Type vs Length field mess, the ISO/IEEE and Xerox 
| Ethernet specs are incompatible from the data link level upwards, 
| (and perhaps even the physical level).
+---------------

Yes, it is a mess, but Xerox tried to salvage what they could.
Your algorithm (look at the "length") should work, according to
private conversations with certain Xerox folk.

UNFORTUNATELY, many people are picking types and using them WITHOUT
registering them with Xerox! (Boo, hiss!) In particular, I don't think
either the 4.2 "trailer protocol" or ARP types are registered with Xerox
(thoufh they are with NIC!), but I also don't know if they may cause a
conflict or not. It is VERY important that EVERYONE use only registered
types. Getting a new type registered is not all that hard, if you can
stand a certain amount of telephone tag (and already have an Ethernet
patent license). (Remember, 802.3 requires a patent license from Xerox.)

+---------------
| 3) What is Xerox's position regarding allocation of Type field values
|    to ISO protocols? Have they reserved the block 0-1500 for use by ISO,
|    (we believe these values correspond to the only valid 802.3 length fields)
|    or have some of these values been allocated to other protocols? We think
|    that PUP in particular has been allocated the value 512, although the
|    4.2 header files are contradictory on this point.
+---------------

Yes, 0-1500 are now reserved for IEEE "length". There apparently WAS one such
value allocated as a private type to some licensee, which they convinced the
licensee to change. Since PUP is "Xerox Private" and "experimental" (obsolete),
you shouldn't run into that problem, unless you have a bunch of "non-products"
like the Alto lying around. (New products use XNS.)

+---------------
| For various political and technical reasons, we believe we will
| have to support BOTH worlds - we can't change entirely to one or
| the other. However, we are prepared to have at least one machine 
| which understands both protocol families.
+---------------

That SHOULD work, if you can convince the IEEE machines to ignore packets
with "bad" lengths.

+---------------
| 1) Is "Ethernet 2" the same as IEEE-802.3 or is it an upgraded version
|    of the original Xerox/DEC/Intel Ethernet specs?
+---------------

Both, sort of. Ethernet 2.0 is the same as one particular choice of all
the options 802.3 gives you; Xerox "upgraded" the spec to conform.

+---------------
| 2) Are the hardware differences between 802.3 and Xerox likely to be a
|    problem in practice?...
+---------------

No. The key words are "in practice". All of the U.S. manufacturers I know of
are REALLY making Ethernet 2.0 devices, and CALLING them "802.3 compatible".
Since 802.3 includes so many choices, saying "802.3 compatible" by itself
is no guarantee of interoperability. Saying (and conforming to) "Ethernet 2.0"
should guarantee interoperability.

+---------------
| 4) Will the following algorithm suffice to distinguish IEEE packets from
|    Xerox packets at the data link level, and pick an appropriate protocol
|    handler? [Look at "length"... >1500 is Xerox.]
+---------------

Yes, except for the problem with unregistered types (see above).

(Please, corrections without flames, if possible. This is based on memory
of conversations of about a year ago.)


Rob Warnock
Systems Architecture Consultant

UUCP:	{ihnp4,ucbvax!dual}!fortune!redwood!rpw3
DDD:	(415)572-2607
USPS:	510 Trinidad Lane, Foster City, CA  94404