EARP proposal

[Vernon Schryver <[e-mail]>]

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.

One of the proposed alternatives included a protocol where a single EARP
frame with a new SNAP encapsulation would be followed by standard ARP,
presumably at the old fashioned repetition rate.  This protocol has
difficulties when any of myriad of possible causes prevents the initial
EARP frame from reaching the intended target.

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."


Vernon Schryver
Silicon Graphics
[e-mail]