Re: DECWRL::"fddi@merit.edu"

Vernon Schryver <vjs%rhyolite.wpd.sgi.com@sgi.com> Fri, 07 September 1990 18:36 UTC

Date: Fri, 07 Sep 1990 11:35:47 -0700
From: Vernon Schryver <vjs%rhyolite.wpd.sgi.com@sgi.com>
Message-Id: <9009071835.AA19152@rhyolite.wpd.sgi.com>
To: "NI1D @FN42eq" <koning@koning.enet.dec.com>
Subject: Re: DECWRL::"fddi@merit.edu"
Cc: fddi@merit.edu
Status: O

> From: "NI1D @FN42eq" <koning@koning.enet.dec.com>
> To: vjs
> Subject: DECWRL::"fddi@merit.edu"
> 
> ARP and EARP
> There really are very few SAFE ways to distinguish EARP messages from
> ARP messages.  The problem is that ARP is non-extensible.  Its frames
> are defined to have a fixed layout, with no optional, additional, or
> variable fields.  Furthermore, the rules for interpreting the device
> type field are not stated (or at least not sufficiently).  As a result
> there exist implementations that don't check this field at all.
>  
> One can construct various proposals based on looking at the code of SOME
> implementations, or the frames as sent by SOME implementations.  But the
> safe way is to look at what ARP, as specified, allows you to do, and assume
> that anything that's allowed (or not explicitly disallowed) is probably
> done by someone.
>  
> As far as I can see, the only safe solution is to have EARP messages use
>a different Protocol_ID.  The objection I heard is that this is a bureaucratic
> hassle.  I fail to understand that objection.  Any organization that has
> an OUI assigned to it by IEEE (such as DoD, Prime, Digital, etc.) is able
> to assign a Protocol_ID in a matter of minutes.
>  
> 	paul


I don't really care one way or the other, but wouldn't it be easier to use
a new ARP "hardware type" in the EARP frame?  You could define the address
format of this new hardware to consist of more than just a 6-byte MAC
address.  It could be a counted, discrimated array of MAC address, port
numbers, and whatever else you consider good.

Well, maybe I do care.  Even if somone does the paper work to get a new
SNAP, I think you should also use a new ARP hardware type.  It is
unaesthetic to use the old ethernet hardware type when the EARP addresses
are so very different.  (Not many ethernet MAC addresses have any notion of
primary or secondary network or of port ID.)


Errr, on rereading all of the above, it seems that Paul is referring to a
new "ethernet" protocol number to go after the familiar 0xaaaa030000.  I
understood the EARP proposal to involve a change in the 0xaaaa030000.
Replacing the following 0x0806 sounds like a good idea, as well as easy to
do.


vjs

Re: DECWRL::"fddi@merit.edu" Vernon Schryver