Path: utzoo!utgpu!water!watmath!clyde!bellcore!faline!thumper!ulysses!andante!princeton!udel!gatech!purdue!decwrl!ucbvax!hplabs!sdcrdcf!darrelj
From: darrelj@sdcrdcf.UUCP
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Many things on ethernet together???
Message-ID: <5276@sdcrdcf.UUCP>
Date: 12 May 88 20:24:00 GMT
References: <18701@watmath.waterloo.edu> <880510-175117-10169@Xerox>
Reply-To: darrelj@sdcrdcf.UUCP (Darrel VanBuer)
Organization: Unisys - System Development Group, Santa Monica
Lines: 26
Posted: Thu May 12 16:24:00 1988

In article <880510-175117-10169@Xerox> RMRichardson.PA@Xerox.COM writes:
>> One thing no-one has mentioned yet is the case where the ethernet type is
>> a valid 802.3 packet length.  I think Xerox PUP falls in to this catagory
>PUP -- PARC Universal Packet
>It means you can't talk PUP to hosts that act that way.  One way around 
>this is to change the PUP type numbers to outside the valid length range.  
>This means all the PUP speakers on the net must all do this or you will 
>have split the net into two types of PUP speakers who can talk to only 



It turns out PUP (and its companion address translation-private ARP type) are
the only protocol numbers which conflict with 802.3 length.  The new type
numbers for 802.3 compatibility are 2048 (decimal) higher than they were,
i.e.
PUP is 2560(dec) or 0x0a00
PUP ARP is 2561(dec).
PUP has endured past its experimental days because of an installed base of
hardware which have come to depend on its services.  One of the features of
most PUP protocols which is both a benefit and a drawback is a slight
blurring of the line between layers (in the interest of bit efficiency to
ensure most useful interchanges fit a single 576 byte MTU packet).
-- 
Darrel J. Van Buer, PhD; unisys; 2400 Colorado Ave; Santa Monica, CA 90406
(213)829-7511 x5449        KI6VY        darrel@CAM.UNISYS.COM   or
...{allegra,burdvax,cbosgd,hplabs,ihnp4}!sdcrdcf!darrelj