Re: DECWRL::""

Vernon Schryver <> Fri, 07 September 1990 18:36 UTC

Received: from by NRI.NRI.Reston.VA.US id aa10263; 7 Sep 90 14:36 EDT
Received: Fri, 7 Sep 90 13:36:06 EST from SGI.COM by (5.59/1.6)
Received: from by SGI.COM via SMTP (5.64-bind 1.5+ida/900410.SGI) for id AA18293; Fri, 7 Sep 90 11:36:00 -0700
Received: from by via SMTP (5.64-bind 1.5+ida/900721.SGI) for!!fddi id AA10882; Fri, 7 Sep 90 11:35:50 -0700
Received: by (5.52/900721.SGI) for id AA19152; Fri, 7 Sep 90 11:35:47 PDT
Date: Fri, 7 Sep 90 11:35:47 PDT
From: Vernon Schryver <>
Message-Id: <>
To: "NI1D @FN42eq" <>
Subject: Re: DECWRL::""
Status: O

> From: "NI1D @FN42eq" <>
> To: vjs
> Subject: DECWRL::""
> 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