Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!pasteur!ucbvax!MONK.PROTEON.COM!jas
From: jas@MONK.PROTEON.COM (John A. Shriver)
Newsgroups: comp.protocols.tcp-ip
Subject: ARP protocol address space field on ProNET
Message-ID: <8803241647.AA04410@monk.proteon.com>
Date: 24 Mar 88 16:47:17 GMT
References: <2815@dalcs.UUCP>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 40

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.