EARP

"NI1D @FN42eq" <koning@koning.enet.dec.com> Fri, 07 September 1990 18:57 UTC

Received: from merit.edu by NRI.NRI.Reston.VA.US id aa10622; 7 Sep 90 14:57 EDT
Received: Fri, 7 Sep 90 13:57:37 EST from decpa.pa.dec.com by merit.edu (5.59/1.6)
Received: by decpa.pa.dec.com; id AA18893; Fri, 7 Sep 90 11:57:32 -0700
Message-Id: <9009071857.AA18893@decpa.pa.dec.com>
Received: from koning.enet; by decwrl.enet; Fri, 7 Sep 90 11:57:33 PDT
Date: Fri, 7 Sep 90 11:57:33 PDT
From: "NI1D @FN42eq" <koning@koning.enet.dec.com>
To: fddi@merit.edu
Subject: EARP
Status: O

The reason for not using the ARP Hardware Type field (by itself) to
identify EARP is that some implementations ignore that field.
 
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.
 
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.
 
The job of (E)ARP is to pass around information about addresses.  What
matters to the other end is NOT the type of hardware involved!  The only
thing that matters is what the addresses mean.  Whether the sender is
speaking FDDI, 802.3, Ethernet, 802.4, or whatever is totally irrelevant
so long as the address rules match.
 
A possible conclusion is that you should have an "address format" field.
That could be done, and would probably not cause the sort of problems
that the Hardware Type field has.  But in fact you don't need to identify
the address format.
 
If you receive a message, its datalink addresses were obviously in the
form that your adapter understands.  So there is no need to represent
inside that message the information that "this message uses the same
addressing format that you do" because you already knew that from the
simple fact of having received it.
 
	paul