Re: EARP
Vernon Schryver <vjs%rhyolite.wpd.sgi.com@sgi.com> Fri, 07 September 1990 21:20 UTC
Received: from merit.edu 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 merit.edu (5.59/1.6)
Received: from whizzer.wpd.sgi.com by SGI.COM via SMTP (5.64-bind 1.5+ida/900410.SGI) for fddi@merit.edu id AA22882; Fri, 7 Sep 90 14:20:40 -0700
Received: from rhyolite.wpd.sgi.com by whizzer.wpd.sgi.com via SMTP (5.64-bind 1.5+ida/900721.SGI) for sgi.sgi.com!merit.edu!fddi id AA14075; Fri, 7 Sep 90 14:20:38 -0700
Received: by rhyolite.wpd.sgi.com (5.52/900721.SGI) for @whizzer.wpd.sgi.com:fddi@merit.edu id AA19505; Fri, 7 Sep 90 14:20:36 PDT
Date: Fri, 07 Sep 1990 14:20:36 -0700
From: Vernon Schryver <vjs%rhyolite.wpd.sgi.com@sgi.com>
Message-Id: <9009072120.AA19505@rhyolite.wpd.sgi.com>
To: fddi@merit.edu
Subject: Re: EARP
Status: O
> From: "NI1D @FN42eq" <koning@koning.enet.dec.com> > > 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. vjs