As per Relevance of the word hardware, we have this rfc below:
Network Working Group Finlayson, Mann, Mogul,
Request for Comments: 903 Stanford
June 1984
A Reverse Address Resolution
Ross Finlayson, Timothy Mann, Jeffrey Mogul, Marvin
Computer Science
Stanford
June 1984
Status of this
This RFC suggests a method for workstations to dynamically find
protocol address (e.g., their Internet Address), when they know
their hardware address (e.g., their attached physical
address).
This RFC specifies a proposed protocol for the ARPA
community, and requests discussion and suggestions for improvements
I.
Network hosts such as diskless workstations frequently do not
their protocol addresses when booted; they often know only
hardware interface addresses. To communicate using higher-
protocols like IP, they must discover their protocol address
some external source. Our problem is that there is no
mechanism for doing so
Plummer's "Address Resolution Protocol" (ARP) [1] is designed
solve a complementary problem, resolving a host's hardware
given its protocol address. This RFC proposes a "Reverse
Resolution Protocol" (RARP). As with ARP, we assume a
medium, such as Ethernet
II. Design
The following considerations guided our design of the RARP protocol
A. ARP and RARP are different operations. ARP assumes that
host knows the mapping between its own hardware address and
address(es). Information gathered about other hosts is
in a small cache. All hosts are equal in status; there is
distinction between clients and servers
On the other hand, RARP requires one or more server hosts to
a database of mappings from hardware address to protocol address
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
databases. It is undesirable and in some cases impossible to
such a database in the kernel of a host's operating system. Thus
most implementations will require some form of interaction with
program outside the kernel
C. Ease of implementation and minimal impact on existing
software are important. It would be a mistake to design a
that required modifications to every host's software, whether or
it intended to participate
D. It is desirable to allow for the possibility of sharing code
existing software, to minimize overhead and development costs
III. The Proposed
We propose that RARP be specified as a separate protocol at
data-link level. For example, if the medium used is Ethernet,
RARP packets will have an Ethertype (still to be assigned)
from that of ARP. This recognizes that ARP and RARP are
fundamentally different operations, not supported equally by
hosts. The impact on existing systems is minimized; existing
servers will not be confused by RARP packets. It makes RARP a
facility that can be used for mapping hardware addresses to
higher level protocol address
This approach provides the simplest implementation for RARP
hosts, but also provides the most difficulties for RARP server hosts
However, these difficulties should not be insurmountable, as is
in Appendix A, where we sketch two possible implementations
4.2BSD Unix
RARP uses the same packet format that is used by ARP, namely
ar$hrd (hardware address space) - 16
ar$pro (protocol address space) - 16
ar$hln (hardware address length) - 8
ar$pln (protocol address length) - 8
ar$op (opcode) - 16
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
ar$tpa (target protocol address) - m
ar$hrd, ar$pro, ar$hln and ar$pln are the same as in regular
(see [1]).
Finlayson, Mann, Mogul, Theimer [Page 2]
RFC 903 June 1984
Suppose, for example, that 'hardware' addresses are 48-bit
addresses, and 'protocol' addresses are 32-bit Internet Addresses
That is, we wish to determine Internet Addresses corresponding
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
opcodes may be passed on to regular ARP code. A packet with
other opcode is undefined. As in ARP, there are no "not found"
"error" packets, since many RARP servers are free to respond to
request. The sender of a RARP request packet should timeout if
does not receive a reply for this request within a reasonable
of time
The ar$sha, ar$spa, $ar$tha, and ar$tpa fields of the RARP packet
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
protocol address, this, like ar$sha, will be the
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
reply packet).
ar$spa is the protocol address of the responder (see the
below).
ar$tha is the hardware address of the target, and should be
same as that which was given in the request
ar$tpa is the protocol address of the target, that is, the
address
Note that the requirement that ar$spa in opcode 4 packets be
Finlayson, Mann, Mogul, Theimer [Page 3]
RFC 903 June 1984
in with the responder's protocol is purely for convenience.
instance, if a system were to use both ARP and RARP, then
inclusion of the valid protocol-hardware address pair (ar$spa
ar$sha) may eliminate the need for a subsequent ARP request
IV.
[1] Plummer, D., "An Ethernet Address Resolution Protocol", RFC 826,
MIT-LCS, November 1982.
Appendix A. Two Example Implementations for 4.2BSD
The following implementation sketches outline two
approaches to implementing a RARP server under 4.2BSD
A. Provide access to data-link level packets outside the kernel.
RARP server is implemented completely outside the kernel
interacts with the kernel only to receive and send RARP packets.
kernel has to be modified to provide the appropriate access for
packets; currently the 4.2 kernel allows access only to IP packets
One existing mechanism that provides this capability is the
"packet-filter" pseudo driver. This has been used successfully
CMU and Stanford to implement similar sorts of "user-level"
servers
B. Maintain a cache of database entries inside the kernel. The
RARP server database is maintained outside the kernel by a
process. The RARP server itself is implemented directly in
kernel and employs a small cache of database entries for
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
new ioctls. (These are like SIOCIFADDR, in that they are not
associated with a specific socket.) One means: "sleep until there
a translation to be done, then pass the request out to the
process"; the other means: "enter this translation into the
table". Thus, when the kernel can't find an entry in the cache,
puts the request on a (global) queue and then does a wakeup().
implementation of the first ioctl is to sleep() and then pull
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
process replies, it can either give up (and assume that
requesting host will retransmit the request packet after a second)
if the second ioctl passes a copy of the request back into
kernel, formulate and send a response at that time
Finlayson, Mann, Mogul, Theimer [Page 4]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
