EARP
Vernon Schryver <vjs%rhyolite.wpd.sgi.com@sgi.com> Thu, 18 October 1990 18:10 UTC
Received: from merit.edu by NRI.NRI.Reston.VA.US id aa08087; 18 Oct 90 14:10 EDT
Received: Thu, 18 Oct 90 13:09:36 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 AA02978; Thu, 18 Oct 90 11:09:28 -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 AA29823; Thu, 18 Oct 90 11:09:24 -0700
Received: by rhyolite.wpd.sgi.com (5.52/900721.SGI) for @whizzer.wpd.sgi.com:CBROWN%enr.prime.com@RELAY.CS.NET id AA03159; Thu, 18 Oct 90 11:09:22 PDT
Date: Thu, 18 Oct 1990 11:09:22 -0700
From: Vernon Schryver <vjs%rhyolite.wpd.sgi.com@sgi.com>
Message-Id: <9010181809.AA03159@rhyolite.wpd.sgi.com>
To: CBROWN%enr.prime.com@relay.cs.net
Subject: EARP
Cc: fddi@merit.edu
Status: O
>From: Caralyn Brown (CBROWN@ENR) > To: vjs > > Ug! I can't believe I waited this long to ask you this question... but well, > here goes... I have the same problem. Maybe now that the Interop disaster is finished we'll all have some time. > > dated Sept 7 > >The recent extended ARP proposal contained two alternatives for new ARP > >requests. This week I was monitoring some frames on a ring, and saw some > >standard ARP frames that contained values that affect one of the > >alternatives. > > >The other suggest alternative was to encode some information in the unused > >target hardware address in the "modified ARP request". This idea was based > >on the expectation that all current IP/FDDI implementations put zero in > >that field. That expectation is consistent with the 4.*BSD code, and > >with the ARP frames generated by many IP/FDDI implementations. > > >Unfortunately, based on my observations this week, there is at least one > >east coast vendor whose IP/FDDI implementation puts a non-zero value in > >that field. Thus, it may be difficult for a station supporting the second > >of the two proposed EARP protocols to distinquish an old fashioned ARP > >request from a modified ARP request containg "encoding of station state and > >path interface (ring) corresponding to sender hardware address." > > > My question is this...who is this east coast vendor and are they a friendly > lot? Perhaps whatever data they are placing in this field is of some > recognizable form and we can simply encode the values needed for EARP in > such a way that EARP will not be confused by this other (non-useful?) > information. > > I am also addressing the other questions that you forwarded to Doug Hunt > and me. Thanks for information both path and present. > > Caralyn Given the circumstances in which I made the observations, I should not name the vendor. They are friendly enough, but I don't think I saw an announced product. The value they were using was all 1's. I twisted arms, and in the test code they had at the site, they changed to 0. However, they are a big company and I doubt the people I tried to convince can change all of their products. I was unable to communicate a reason they found compelling more than "trust me," because they do not plan dual-MAC products. The point of my observation was not that a particular vendor was putting a particular non-zero value in the field. The point is that in the real world, anything not illegal is done by someone. Since there it is not illegal to put any one of the 2**48-1 non-zero values on the unused ARP fields, if we wait long enough, we will encounter someone putting any value we chose into the field. Given ether-to-FDDI bridges, all of the zillions of IP/ethernet implementations, including PC's, have a chance to help us. vjs