jas@MONK.PROTEON.COM (John A. Shriver) (03/25/88)
Well, being as someone is calling my implmentation of ARP non-standard, I will speak to the issue of the Protocol Address Space in ARP for ProNET. The first implementation of ARP on ProNET was done at Carnegie-Mellon University, for the IP protocols. (IP normally does not use ARP on ProNET, but CMU's routing scheme at the time was based on ARP subnet routing, so they needed ARP.) At that time, the table of ARP Hardware Address Space types were not in the current version of Assigned Numbers, since the only value was 1 (Ethernet), which is specified in 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. 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. Currently, three protocols have been used with ARP on ProNET: 1. IP (only at CMU, between 32 bit IP addresses and 8 nit node addresses) 14. XNS (between 48 bit XNS host addresses and 8 bit node addresses) 20. DECnet (between 48 bit DECnet/Ethernet addresses and 8 bit node addresses) Yes, writing a multi-hardware multi-protocol implementation of ARP is interesting, since there are all these variable-sized peices, and different Protocol Address spaces. Oh yes, the "standardness" level of an RFC depends on how and whether it is cited in the current version of the "Official Internet Protocols" RFC. The current version of this RFC can be considered the top of the tree. Also, there will always be interpretation issues with standards. ProNET ARP is just one example.
DCP@QUABBIN.SCRC.Symbolics.COM (David C. Plummer) (03/25/88)
Date: Thu, 24 Mar 88 11:47:17 EST
From: jas@monk.proteon.com (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.karn@thumper.bellcore.com (Phil R. Karn) (03/26/88)
It was pretty apparent to me when I did the ARP-on-AX.25 (amateur packet radio link protocol) implementation that I should use the universe of AX.25 packet types in the ARP protocol field. (The only one that is relevant is CC hex, which means "DoD IP"). Phil
mshiels@watmath.waterloo.edu (Michael A. Shiels) (03/27/88)
Is it possible to get the codes that PRONET does use?? -- Michael A. Shiels (MaS Network Software) mshiels@watmath.waterloo.EDU UUCP: ...path...!watmath!mshiels
jas@MONK.PROTEON.COM (John A. Shriver) (03/29/88)
Well, we keep a copy in all the manuals, but I'll post it anyways, since some of those are getting dated. Quite a few proprietary (customer) protocols are supressed in this list, sorry. At least we'll post most of it, unlike Xerox/ANSI on Ethernet. Proteon ProNET-10/80 data link types: 1 IP 2 IP with trailing headers 3 Address Resoloution Protocol 4 Proteon HDLC 5 VAX Debugging Protocol (MIT) 10 Novell NetWare 11 Vianetix 12 PUP 13 Watstar protocol (University of Waterloo) 14 XNS 15 Diganostics 16 Echo protocol (link level) 17 Banyon Vines 20 DECnet (DEUNA Emulation) 21 Chaosnet 23 IEEE 802.2 or ISO 8802/2 Data Link 24 Reverse Address Resolution Protocol 29 TokenVIEW-10 Just because a protocol is on this list does not mean that there is any implementation of it on ProNET. Of these, protocols 1, 14, and 20 are the only ones that have ever been seen in ARP packets to my knowledge. For reference, the header is (one byte/line): destination hardware address source hardware address data link header version (2) data link header protocol number data link header reserved (0) data link header reserved (0) Some protocols have been known to tuck stuff in the reserved fields. Those who need a protocol number on ProNET-10/80 should contact me (jas@proteon.com).