ARP and EARP

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

Received: from merit.edu by NRI.NRI.Reston.VA.US id aa09700; 7 Sep 90 14:14 EDT
Received: Fri, 7 Sep 90 13:13:11 EST from decpa.pa.dec.com by merit.edu (5.59/1.6)
Received: by decpa.pa.dec.com; id AA14377; Fri, 7 Sep 90 11:12:34 -0700
Message-Id: <9009071812.AA14377@decpa.pa.dec.com>
Received: from koning.enet; by decwrl.enet; Fri, 7 Sep 90 11:12:45 PDT
Date: Fri, 07 Sep 1990 11:12:45 -0700
From: "NI1D @FN42eq" <koning@koning.enet.dec.com>
To: vjs@rhyolite.wpd.sgi.com
Cc: "fddi@merit.edu"@decwrl.dec.com
Subject: ARP and EARP
Status: O

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