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 90 11:09:22 PDT
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

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.