Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!pasteur!ucbvax!QUABBIN.SCRC.Symbolics.COM!DCP From: DCP@QUABBIN.SCRC.Symbolics.COM (David C. Plummer) Newsgroups: comp.protocols.tcp-ip Subject: ARP protocol address space field on ProNET Message-ID: <19880324204643.6.DCP@SWAN.SCRC.Symbolics.COM> Date: 24 Mar 88 20:46:00 GMT References: <8803241647.AA04410@monk.proteon.com> Sender: usenet@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 34 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.