doc: Add RFC documents

1 files changed, 227 insertions, 0 deletions

diff --git a/doc/rfc/rfc903.txt b/doc/rfc/rfc903.txt
new file mode 100644
index 0000000..663e7d6
--- /dev/null
+++ b/doc/rfc/rfc903.txt
@@ -0,0 +1,227 @@
+
+Network Working Group                    Finlayson, Mann, Mogul, Theimer
+Request for Comments: 903                            Stanford University
+                                                               June 1984
+
+                 A Reverse Address Resolution Protocol
+
+
+      Ross Finlayson, Timothy Mann, Jeffrey Mogul, Marvin Theimer
+                      Computer Science Department
+                          Stanford University
+                               June 1984
+
+Status of this Memo
+
+   This RFC suggests a method for workstations to dynamically find their
+   protocol address (e.g., their Internet Address), when they know only
+   their hardware address (e.g., their attached physical network
+   address).
+
+   This RFC specifies a proposed protocol for the ARPA Internet
+   community, and requests discussion and suggestions for improvements.
+
+I. Introduction
+
+   Network hosts such as diskless workstations frequently do not know
+   their protocol addresses when booted; they often know only their
+   hardware interface addresses.  To communicate using higher-level
+   protocols like IP, they must discover their protocol address from
+   some external source.  Our problem is that there is no standard
+   mechanism for doing so.
+
+   Plummer's "Address Resolution Protocol" (ARP) [1] is designed to
+   solve a complementary problem, resolving a host's hardware address
+   given its protocol address.  This RFC proposes a "Reverse Address
+   Resolution Protocol" (RARP).  As with ARP, we assume a broadcast
+   medium, such as Ethernet.
+
+II. Design Considerations
+
+   The following considerations guided our design of the RARP protocol.
+
+   A. ARP and RARP are different operations.  ARP assumes that every
+   host knows the mapping between its own hardware address and protocol
+   address(es).  Information gathered about other hosts is accumulated
+   in a small cache.  All hosts are equal in status; there is no
+   distinction between clients and servers.
+
+   On the other hand, RARP requires one or more server hosts to maintain
+   a database of mappings from hardware address to protocol address and
+   respond to requests from client hosts.
+
+
+
+Finlayson, Mann, Mogul, Theimer                                 [Page 1]
+
+
+
+RFC 903                                                        June 1984
+
+
+   B. As mentioned, RARP requires that server hosts maintain large
+   databases. It is undesirable and in some cases impossible to maintain
+   such a database in the kernel of a host's operating system.  Thus,
+   most implementations will require some form of interaction with a
+   program outside the kernel.
+
+   C. Ease of implementation and minimal impact on existing host
+   software are important.  It would be a mistake to design a protocol
+   that required modifications to every host's software, whether or not
+   it intended to participate.
+
+   D. It is desirable to allow for the possibility of sharing code with
+   existing software, to minimize overhead and development costs.
+
+III.  The Proposed Protocol
+
+   We propose that RARP be specified as a separate protocol at the
+   data-link level.  For example, if the medium used is Ethernet, then
+   RARP packets will have an Ethertype (still to be assigned) different
+   from that of ARP.  This recognizes that ARP and RARP are two
+   fundamentally different operations, not supported equally by all
+   hosts.  The impact on existing systems is minimized; existing ARP
+   servers will not be confused by RARP packets. It makes RARP a general
+   facility that can be used for mapping hardware addresses to any
+   higher level protocol address.
+
+   This approach provides the simplest implementation for RARP client
+   hosts, but also provides the most difficulties for RARP server hosts.
+   However, these difficulties should not be insurmountable, as is shown
+   in Appendix A, where we sketch two possible implementations for
+   4.2BSD Unix.
+
+   RARP uses the same packet format that is used by ARP, namely:
+
+      ar$hrd (hardware address space) -  16 bits
+      ar$pro (protocol address space) -  16 bits
+      ar$hln (hardware address length) - 8 bits
+      ar$pln (protocol address length) - 8 bits
+      ar$op  (opcode) - 16 bits
+      ar$sha (source hardware address) - n bytes,
+                                       where n is from the ar$hln field.
+      ar$spa (source protocol address) - m bytes,
+                                       where m is from the ar$pln field.
+      ar$tha (target hardware address) - n bytes
+      ar$tpa (target protocol address) - m bytes
+
+   ar$hrd, ar$pro, ar$hln and ar$pln are the same as in regular ARP
+   (see [1]).
+
+
+Finlayson, Mann, Mogul, Theimer                                 [Page 2]
+
+
+
+RFC 903                                                        June 1984
+
+
+   Suppose, for example, that 'hardware' addresses are 48-bit Ethernet
+   addresses, and 'protocol' addresses are 32-bit Internet Addresses.
+   That is, we wish to determine Internet Addresses corresponding to
+   known Ethernet addresses.  Then, in each RARP packet, ar$hrd = 1
+   (Ethernet), ar$pro = 2048 decimal (the Ethertype of IP packets),
+   ar$hln = 6, and ar$pln = 4.
+
+   There are two opcodes: 3 ('request reverse') and 4 ('reply reverse').
+   An opcode of 1 or 2 has the same meaning as in [1]; packets with such
+   opcodes may be passed on to regular ARP code.  A packet with any
+   other opcode is undefined.  As in ARP, there are no "not found" or
+   "error" packets, since many RARP servers are free to respond to a
+   request.  The sender of a RARP request packet should timeout if it
+   does not receive a reply for this request within a reasonable amount
+   of time.
+
+   The ar$sha, ar$spa, $ar$tha, and ar$tpa fields of the RARP packet are
+   interpreted as follows:
+
+   When the opcode is 3 ('request reverse'):
+
+      ar$sha is the hardware address of the sender of the packet.
+
+      ar$spa is undefined.
+
+      ar$tha is the 'target' hardware address.
+
+         In the case where the sender wishes to determine his own
+         protocol address, this, like ar$sha, will be the hardware
+         address of the sender.
+
+      ar$tpa is undefined.
+
+   When the opcode is 4 ('reply reverse'):
+
+      ar$sha is the hardware address of the responder (the sender of the
+      reply packet).
+
+      ar$spa is the protocol address of the responder (see the note
+      below).
+
+      ar$tha is the hardware address of the target, and should be the
+      same as that which was given in the request.
+
+      ar$tpa is the protocol address of the target, that is, the desired
+      address.
+
+   Note that the requirement that ar$spa in opcode 4 packets be filled
+
+
+Finlayson, Mann, Mogul, Theimer                                 [Page 3]
+
+
+
+RFC 903                                                        June 1984
+
+
+   in with the responder's protocol is purely for convenience.  For
+   instance, if a system were to use both ARP and RARP, then the
+   inclusion of the valid protocol-hardware address pair (ar$spa,
+   ar$sha) may eliminate the need for a subsequent ARP request.
+
+IV. References
+
+   [1] Plummer, D., "An Ethernet Address Resolution Protocol",  RFC 826,
+   MIT-LCS, November 1982.
+
+Appendix A.  Two Example Implementations for 4.2BSD Unix
+
+   The following implementation sketches outline two different
+   approaches to implementing a RARP server under 4.2BSD.
+
+   A. Provide access to data-link level packets outside the kernel.  The
+   RARP server is implemented completely outside the kernel and
+   interacts with the kernel only to receive and send RARP packets.  The
+   kernel has to be modified to provide the appropriate access for these
+   packets; currently the 4.2 kernel allows access only to IP packets.
+   One existing mechanism that provides this capability is the CMU
+   "packet-filter" pseudo driver.  This has been used successfully at
+   CMU and Stanford to implement similar sorts of "user-level" network
+   servers.
+
+   B. Maintain a cache of database entries inside the kernel.  The full
+   RARP server database is maintained outside the kernel by a user
+   process.  The RARP server itself is implemented directly in the
+   kernel and employs a small cache of database entries for its
+   responses.  This cache could be the same as is used for forward ARP.
+
+   The cache gets filled from the actual RARP database by means of two
+   new ioctls.  (These are like SIOCIFADDR, in that they are not really
+   associated with a specific socket.)  One means: "sleep until there is
+   a translation to be done, then pass the request out to the user
+   process"; the other means: "enter this translation into the kernel
+   table".  Thus, when the kernel can't find an entry in the cache, it
+   puts the request on a (global) queue and then does a wakeup().  The
+   implementation of the first ioctl is to sleep() and then pull the
+   first item off of this queue and return it to the user process.
+   Since the kernel can't wait around at interrupt level until the user
+   process replies, it can either give up (and assume that the
+   requesting host will retransmit the request packet after a second) or
+   if the second ioctl passes a copy of the request back into the
+   kernel, formulate and send a response at that time.
+
+
+
+
+
+Finlayson, Mann, Mogul, Theimer                                 [Page 4]
+