Inverse Address Resolution Protocol
RFC 1293

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
 environment in which InARP is running. For example, if IP is running
 over Frame Relay, the hardware address length is between 2 and 4, and
 the protocol address length is 4.
 The operation code indicates the type of message, request or reply.
 InARP request = 8
 InARP reply = 9
 These values were chosen so as not to conflict with other ARP
 extensions.
7. Protocol Operation
 Basic InARP operates essentially the same as ARP with the exception
 that InARP does not broadcast requests. This is because the hardware
 address of the destination station is already known. A requesting
 station simply formats a request by inserting its source hardware and
 protocol addresses and the known target hardware address. It then
 zero fills the target protocol address field. Finally, it will
 encapsulate the packet for the specific network and send it directly
 to the target station.
 Upon receiving an InARP request, a station may put the requester's
 protocol address/hardware address mapping into its ARP cache as it
 would any ARP request. Unlike other ARP requests, however, the
 receiving station may assume that any InARP request it receives is
 destined for it. For every InARP request, the receiving station may
 format a proper reply using the source addresses from the request as
 the target addresses of the reply. If the station is unable or
 unwilling to reply, it ignores the request.
 When the requesting station receives the InARP reply, it may complete
 the ARP table entry and use the provided address information. Note:
 as with ARP, information learned via InARP may be aged or invalidated
 under certain circumstances.
7.1. Operation with Multi-Addressed Hosts
 In the context of this discussion, a Multi-Addressed host will refer
 to a host that has multiple protocol addresses assigned to a single
 interface. If such a station receives an InARP request, it must
 choose one address with which to respond. To make such a selection,
 the receiving station must first look at the protocol address of the
Bradley, Brown [Page 3]
RFC 1293 Inverse ARP January 1992
 requesting station, and then respond with the protocol address
 corresponding to the network of the requester. For example, if the
 requesting station is probing for an IP address, the responding
 multi-addressed station should respond with an IP address which
 corresponds to the same subnet as the requesting station. If the
 station does not have an address that is appropriate for the request
 it should not respond. In the IP example, if the receiving station
 does not have an IP address assigned to the interface that is a part
 of the requested subnet, the receiving station would not respond.
 A multi-addressed host may choose to send an InARP request for each
 of the addresses defined for the given interface. It should be
 noted, however, that the receiving side may answer some or none of
 the requests depending on its configuration.
7.2. Protocol Operation Within Frame Relay
 One case where Inverse ARP can be used is when a new virtual circuit
 is signalled. The Frame Relay station may format an InARP request
 addressed to the new virtual circuit. If the other side supports
 InARP, it may return a reply indicating the protocol address
 requested.
 The format for an InARP request is a follows:
 ar$hrd - 0x000F the value assigned to Frame Relay
 ar$pro - protocol type for which you are searching
 (i.e. IP = 0x0800)
 ar$hln - 2,3, or 4 byte addressing length
 ar$pln - byte length of protocol address for which you
 are searching (for IP = 4)
 ar$op - 8; InARP request
 ar$sha - Q.922 address of requesting station
 ar$spa - protocol address of requesting station
 ar$tha - Q.922 addressed of newly announced virtual circuit
 ar$tpa - 0; This is what we're looking for
Bradley, Brown [Page 4]
RFC 1293 Inverse ARP January 1992
 The InARP response will be completed similarly.
 ar$hrd - 0x000F the value assigned to Frame Relay
 ar$pro - protocol type for which you are searching
 (i.e. IP = 0x0800)
 ar$hln - 2,3, or 4 byte addressing length
 ar$pln - byte length of protocol address for which you
 are searching (for IP = 4)
 ar$op - 9; InARP response
 ar$sha - Q.922 address of responding station
 ar$spa - protocol address requested
 ar$tha - Q.922 address of requesting station
 ar$tpa - protocol address of requesting station
 Note that the Q.922 addresses specified have the C/R, FECN, BECN, and
 DE bits set to zero.
 Procedures for using InARP over a Frame Relay network are identical
 to those for using ARP and RARP discussed in section 10 of the
 Multiprotocol Interconnect over Frame Relay Networks document [3].
8. References
 [1] Plummer, David C., "An Ethernet Address Resolution Protocol",
 RFC-826, November 1982.
 [2] Reynolds, J. and Postel, J., "Assigned Numbers", RFC-1060, ISI,
 March 1990.
 [3] Bradley, T., Brown, C., Malis, A., "Multiprotocol Interconnect
 over Frame Relay Networks", RFC-1294, January 1992.
 [4] Finlayson, Mann, Mogul, Theimer, "A Reverse Address Resolution
 Protocol", RFC-903, Stanford University, June 1984.
9. Security Considerations
 Security issues are not addressed in this memo.
Bradley, Brown [Page 5]
RFC 1293 Inverse ARP January 1992
10. Authors' Addresses
 Terry Bradley
 Wellfleet Communications, Inc.
 15 Crosby Drive
 Bedford, MA 01730
 Phone: (617) 275-2400
 Email: tbradley@wellfleet.com
 Caralyn Brown
 Wellfleet Communications, Inc.
 15 Crosby Drive
 Bedford, MA 01730
 Phone: (617) 275-2400
 Email: cbrown@wellfleet.com
Bradley, Brown [Page 6]