Vernon Schryver <> Fri, 07 September 1990 21:20 UTC

Received: from by NRI.NRI.Reston.VA.US id aa13021; 7 Sep 90 17:20 EDT
Received: Fri, 7 Sep 90 16:20:43 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 AA22882; Fri, 7 Sep 90 14:20:40 -0700
Received: from by via SMTP (5.64-bind 1.5+ida/900721.SGI) for!!fddi id AA14075; Fri, 7 Sep 90 14:20:38 -0700
Received: by (5.52/900721.SGI) for id AA19505; Fri, 7 Sep 90 14:20:36 PDT
Date: Fri, 7 Sep 90 14:20:36 PDT
From: Vernon Schryver <>
Message-Id: <>
Subject: Re: EARP
Status: O

> From: "NI1D @FN42eq" <>
> The reason for not using the ARP Hardware Type field (by itself) to
> identify EARP is that some implementations ignore that field.

Good point.

> By "Protocol_ID" I meant the 5-byte field that follows the AA-AA-03 --
> for example, in ARP that is 00-00-00-08-06.  One alternative is to
> use 00-00-00 for the first 3 bytes, in which case the task amounts to
> getting another EtherType.  Xerox (I assume still) hands those out.
> If you don't insist on an EtherType (i.e., you're willing to accept
> values other than 00-00-00 in the first 3 bytes of the Protocol_ID) then
> there are lots of others that could provide the value, probably sooner.

It is possible that some vendor might have a spare Xerox EtherType to
contribute to the cause.  For example, last year Silicon Graphics gave an
EtherType that had long ago been assigned to a protocol that faded to a
company that is now working on a new protocol.  I fear we don't have any
more spares; does anyone else?

> As for the question of what the Hardware Type field in the EARP message
> should be: I would propose that there should be no such field!  The reason
> is that it's presence in the ARP message has been a source of hassle and
> does not in fact serve any purpose.

>  ...

seems reasonable.