home *** CD-ROM | disk | FTP | other *** search
/ Unix System Administration Handbook 1997 October / usah_oct97.iso / rfc / 900s / rfc903.txt < prev    next >
Text File  |  1992-09-22  |  9KB  |  228 lines
  1.  
  2. Network Working Group                    Finlayson, Mann, Mogul, Theimer
  3. Request for Comments: 903                            Stanford University
  4.                                                                June 1984
  5.  
  6.                  A Reverse Address Resolution Protocol
  7.  
  8.  
  9.       Ross Finlayson, Timothy Mann, Jeffrey Mogul, Marvin Theimer
  10.                       Computer Science Department
  11.                           Stanford University
  12.                                June 1984
  13.  
  14. Status of this Memo
  15.  
  16.    This RFC suggests a method for workstations to dynamically find their
  17.    protocol address (e.g., their Internet Address), when they know only
  18.    their hardware address (e.g., their attached physical network
  19.    address).
  20.  
  21.    This RFC specifies a proposed protocol for the ARPA Internet
  22.    community, and requests discussion and suggestions for improvements.
  23.  
  24. I. Introduction
  25.  
  26.    Network hosts such as diskless workstations frequently do not know
  27.    their protocol addresses when booted; they often know only their
  28.    hardware interface addresses.  To communicate using higher-level
  29.    protocols like IP, they must discover their protocol address from
  30.    some external source.  Our problem is that there is no standard
  31.    mechanism for doing so.
  32.  
  33.    Plummer's "Address Resolution Protocol" (ARP) [1] is designed to
  34.    solve a complementary problem, resolving a host's hardware address
  35.    given its protocol address.  This RFC proposes a "Reverse Address
  36.    Resolution Protocol" (RARP).  As with ARP, we assume a broadcast
  37.    medium, such as Ethernet.
  38.  
  39. II. Design Considerations
  40.  
  41.    The following considerations guided our design of the RARP protocol.
  42.  
  43.    A. ARP and RARP are different operations.  ARP assumes that every
  44.    host knows the mapping between its own hardware address and protocol
  45.    address(es).  Information gathered about other hosts is accumulated
  46.    in a small cache.  All hosts are equal in status; there is no
  47.    distinction between clients and servers.
  48.  
  49.    On the other hand, RARP requires one or more server hosts to maintain
  50.    a database of mappings from hardware address to protocol address and
  51.    respond to requests from client hosts.
  52.  
  53.  
  54.  
  55. Finlayson, Mann, Mogul, Theimer                                 [Page 1]
  56.  
  57.  
  58.  
  59. RFC 903                                                        June 1984
  60.  
  61.  
  62.    B. As mentioned, RARP requires that server hosts maintain large
  63.    databases. It is undesirable and in some cases impossible to maintain
  64.    such a database in the kernel of a host's operating system.  Thus,
  65.    most implementations will require some form of interaction with a
  66.    program outside the kernel.
  67.  
  68.    C. Ease of implementation and minimal impact on existing host
  69.    software are important.  It would be a mistake to design a protocol
  70.    that required modifications to every host's software, whether or not
  71.    it intended to participate.
  72.  
  73.    D. It is desirable to allow for the possibility of sharing code with
  74.    existing software, to minimize overhead and development costs.
  75.  
  76. III.  The Proposed Protocol
  77.  
  78.    We propose that RARP be specified as a separate protocol at the
  79.    data-link level.  For example, if the medium used is Ethernet, then
  80.    RARP packets will have an Ethertype (still to be assigned) different
  81.    from that of ARP.  This recognizes that ARP and RARP are two
  82.    fundamentally different operations, not supported equally by all
  83.    hosts.  The impact on existing systems is minimized; existing ARP
  84.    servers will not be confused by RARP packets. It makes RARP a general
  85.    facility that can be used for mapping hardware addresses to any
  86.    higher level protocol address.
  87.  
  88.    This approach provides the simplest implementation for RARP client
  89.    hosts, but also provides the most difficulties for RARP server hosts.
  90.    However, these difficulties should not be insurmountable, as is shown
  91.    in Appendix A, where we sketch two possible implementations for
  92.    4.2BSD Unix.
  93.  
  94.    RARP uses the same packet format that is used by ARP, namely:
  95.  
  96.       ar$hrd (hardware address space) -  16 bits
  97.       ar$pro (protocol address space) -  16 bits
  98.       ar$hln (hardware address length) - 8 bits
  99.       ar$pln (protocol address length) - 8 bits
  100.       ar$op  (opcode) - 16 bits
  101.       ar$sha (source hardware address) - n bytes,
  102.                                        where n is from the ar$hln field.
  103.       ar$spa (source protocol address) - m bytes,
  104.                                        where m is from the ar$pln field.
  105.       ar$tha (target hardware address) - n bytes
  106.       ar$tpa (target protocol address) - m bytes
  107.  
  108.    ar$hrd, ar$pro, ar$hln and ar$pln are the same as in regular ARP
  109.    (see [1]).
  110.  
  111.  
  112. Finlayson, Mann, Mogul, Theimer                                 [Page 2]
  113.  
  114.  
  115.  
  116. RFC 903                                                        June 1984
  117.  
  118.  
  119.    Suppose, for example, that 'hardware' addresses are 48-bit Ethernet
  120.    addresses, and 'protocol' addresses are 32-bit Internet Addresses.
  121.    That is, we wish to determine Internet Addresses corresponding to
  122.    known Ethernet addresses.  Then, in each RARP packet, ar$hrd = 1
  123.    (Ethernet), ar$pro = 2048 decimal (the Ethertype of IP packets),
  124.    ar$hln = 6, and ar$pln = 4.
  125.  
  126.    There are two opcodes: 3 ('request reverse') and 4 ('reply reverse').
  127.    An opcode of 1 or 2 has the same meaning as in [1]; packets with such
  128.    opcodes may be passed on to regular ARP code.  A packet with any
  129.    other opcode is undefined.  As in ARP, there are no "not found" or
  130.    "error" packets, since many RARP servers are free to respond to a
  131.    request.  The sender of a RARP request packet should timeout if it
  132.    does not receive a reply for this request within a reasonable amount
  133.    of time.
  134.  
  135.    The ar$sha, ar$spa, $ar$tha, and ar$tpa fields of the RARP packet are
  136.    interpreted as follows:
  137.  
  138.    When the opcode is 3 ('request reverse'):
  139.  
  140.       ar$sha is the hardware address of the sender of the packet.
  141.  
  142.       ar$spa is undefined.
  143.  
  144.       ar$tha is the 'target' hardware address.
  145.  
  146.          In the case where the sender wishes to determine his own
  147.          protocol address, this, like ar$sha, will be the hardware
  148.          address of the sender.
  149.  
  150.       ar$tpa is undefined.
  151.  
  152.    When the opcode is 4 ('reply reverse'):
  153.  
  154.       ar$sha is the hardware address of the responder (the sender of the
  155.       reply packet).
  156.  
  157.       ar$spa is the protocol address of the responder (see the note
  158.       below).
  159.  
  160.       ar$tha is the hardware address of the target, and should be the
  161.       same as that which was given in the request.
  162.  
  163.       ar$tpa is the protocol address of the target, that is, the desired
  164.       address.
  165.  
  166.    Note that the requirement that ar$spa in opcode 4 packets be filled
  167.  
  168.  
  169. Finlayson, Mann, Mogul, Theimer                                 [Page 3]
  170.  
  171.  
  172.  
  173. RFC 903                                                        June 1984
  174.  
  175.  
  176.    in with the responder's protocol is purely for convenience.  For
  177.    instance, if a system were to use both ARP and RARP, then the
  178.    inclusion of the valid protocol-hardware address pair (ar$spa,
  179.    ar$sha) may eliminate the need for a subsequent ARP request.
  180.  
  181. IV. References
  182.  
  183.    [1] Plummer, D., "An Ethernet Address Resolution Protocol",  RFC 826,
  184.    MIT-LCS, November 1982.
  185.  
  186. Appendix A.  Two Example Implementations for 4.2BSD Unix
  187.  
  188.    The following implementation sketches outline two different
  189.    approaches to implementing a RARP server under 4.2BSD.
  190.  
  191.    A. Provide access to data-link level packets outside the kernel.  The
  192.    RARP server is implemented completely outside the kernel and
  193.    interacts with the kernel only to receive and send RARP packets.  The
  194.    kernel has to be modified to provide the appropriate access for these
  195.    packets; currently the 4.2 kernel allows access only to IP packets.
  196.    One existing mechanism that provides this capability is the CMU
  197.    "packet-filter" pseudo driver.  This has been used successfully at
  198.    CMU and Stanford to implement similar sorts of "user-level" network
  199.    servers.
  200.  
  201.    B. Maintain a cache of database entries inside the kernel.  The full
  202.    RARP server database is maintained outside the kernel by a user
  203.    process.  The RARP server itself is implemented directly in the
  204.    kernel and employs a small cache of database entries for its
  205.    responses.  This cache could be the same as is used for forward ARP.
  206.  
  207.    The cache gets filled from the actual RARP database by means of two
  208.    new ioctls.  (These are like SIOCIFADDR, in that they are not really
  209.    associated with a specific socket.)  One means: "sleep until there is
  210.    a translation to be done, then pass the request out to the user
  211.    process"; the other means: "enter this translation into the kernel
  212.    table".  Thus, when the kernel can't find an entry in the cache, it
  213.    puts the request on a (global) queue and then does a wakeup().  The
  214.    implementation of the first ioctl is to sleep() and then pull the
  215.    first item off of this queue and return it to the user process.
  216.    Since the kernel can't wait around at interrupt level until the user
  217.    process replies, it can either give up (and assume that the
  218.    requesting host will retransmit the request packet after a second) or
  219.    if the second ioctl passes a copy of the request back into the
  220.    kernel, formulate and send a response at that time.
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Finlayson, Mann, Mogul, Theimer                                 [Page 4]
  227.  
  228.