David C. Plummer (DCP@QUABBIN.SCRC.Symbolics.COM)
Thu, 24 Mar 88 15:46 EST
Date: Thu, 24 Mar 88 11:47:17 EST
From: firstname.lastname@example.org (John A. Shriver)
Being the author of ARP...
As we read RFC 826 (ARP), it only claimed that the Protocol Address
Space field was chosen from the field of Ethernet types if the
Hardware Address Space was Ethernet. We decided (by default, really)
that it was obvious that we should use the space of ProNET types for
ProNET. Aside from reasons of symmetry, the more important reason is
that there might well be protocols on ProNET which do not have
Ethernet types, but do need to use ARP. Indeed, this is currently the
case for some protocols on ProNET.
... this was certainly the intention. When I heard the ProNet did not
use Ethernet types for their protocol dispatching field, I found that
"unfortunate." The reasons they chose to be different may be good or
bad; I'm not concerned about that here.
The versions of assigned numbers that stated that Protocol Address
Space would always be Ethernet types came long after our ARPs were in
the field. I have noted this discrepancy to the NIC before.
The NIC is wrong, both by the intent and by the literal reading of the
RFC. The fact that some other hardware types (e.g., packet radio,
certain serial links, etc) also use the 10MBit Ethernet hardware type
for ar$pro is a perfectly reasonable design convenience, but that's
where it stops: it is a convenience.
Summary: The NIC overstepped its authority by asserting that ar$pro is
always taken from the set of ethernet types. Proteon did a reasonable
and valid thing in defining ar$pro to come from a different and rational
set of types.
This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:41:31 GMT