Inverse Address Resolution Protocol
RFC 1293

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 03

Network Working Group                                         T. Bradley
Request for Comments: 1293                                      C. Brown
                                          Wellfleet Communications, Inc.
                                                            January 1992

                  Inverse Address Resolution Protocol

1.  Status of this Memo

   This RFC specifies an IAB standards track protocol for the Internet
   community, and requests discussion and suggestions for improvements.
   Please refer to the current edition of the "IAB Official Protocol
   Standards" for the standardization state and status of this protocol.
   Distribution of this memo is unlimited.

2.  Abstract

   This memo describes additions to ARP that will allow a station to
   request a protocol address corresponding to a given hardware address.
   Specifically, this applies to Frame Relay stations that may have a
   Data Link Connection Identifier (DLCI), the Frame Relay equivalent of
   a hardware address, associated with an established Permanent Virtual
   Circuit (PVC), but do not know the protocol address of the station on
   the other side of this connection.  It will also apply to other
   networks with similar circumstances.

3.  Conventions

   The following language conventions are used in the items of
   specification in this document:

     o Must, Will, Shall or Mandatory -- the item is an absolute
       requirement of the specification.

     o Should or Recommended -- the item should generally be
       followed for all but exceptional circumstances.

     o May or Optional -- the item is truly optional and may be
       followed or ignored according to the needs of the
       implementor.

4.  Introduction

   This document will rely heavily on Frame Relay as an example of how
   the Inverse Address Resolution Protocol (InARP) can be useful. It is
   not, however, intended that InARP be used exclusively with Frame
   Relay.  InARP may be used in any network that provides destination
   hardware addresses without indicating corresponding protocol

Bradley, Brown                                                  [Page 1]
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                                                  [Page 2]
RFC 1293                      Inverse ARP                   January 1992

   Possible values for hardware and protocol types are the same as those
   for ARP and may be found in the current Assigned Numbers RFC [2].

   Length of the hardware and protocol address are dependent on the