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
- ARP and EARP NI1D @FN42eq