RFC 1293 (rfc1293) - Page 2 of 6

Inverse Address Resolution Protocol

RFC 1293                      Inverse ARP                   January 1992


   addresses.

5.  Motivation

   The motivation for the development of Inverse ARP is a result of the
   desire to make dynamic address resolution within Frame Relay both
   possible and efficient.  Permanent virtual circuits (PVCs) and
   eventually switched virtual circuits (SVCs) are identified by a Data
   Link Connection Identifier (DLCI).  These DLCIs define a single
   virtual connection through the wide area network (WAN) and are the
   Frame Relay equivalent to a hardware address.  Periodically, through
   the exchange of signalling messages, a network may announce a new
   virtual circuit with its corresponding DLCI.  Unfortunately, protocol
   addressing is not included in the announcement.  The station
   receiving such an indication will learn of the new connection, but
   will not be able to address the other side.  Without a new
   configuration or mechanism for discovering the protocol address of
   the other side, this new virtual circuit is unusable.

   Other resolution methods were considered to solve the problems, but
   were rejected.  Reverse ARP [4], for example, seemed like a good
   candidate, but the response to a request is the protocol address of
   the requesting station not the station receiving the request as we
   wanted.  IP specific mechanisms were limiting since we wished to
   allow protocol address resolution of many protocols.  For this
   reason, we expanded the ARP protocol.

   Inverse Address Resolution Protocol (InARP) will allow a Frame Relay
   station to discover the protocol address of a station associated with
   the virtual circuit.  It is more efficiently than simulating a
   broadcast with multiple copies of the same message and it is more
   flexible than relying on static configuration.

6.  Packet Format

   Inverse ARP is an extension of the existing ARP.  Therefore, it has
   the same format as standard ARP.

      ar$hrd   16 bits         Hardware type
      ar$pro   16 bits         Protocol type
      ar$hln    8 bits         Byte length of each hardware address (n)
      ar$pln    8 bits         Byte length of each protocol address (m)
      ar$op    16 bits         Operation code
      ar$sha    nbytes         source hardware address
      ar$spa    mbytes         source protocol address
      ar$tha    nbytes         target hardware address
      ar$tpa    mbytes         target protocol address




Bradley, Brown