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:
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 addresses.
Bradley, Brown [Page 1]
RFC 1293 Inverse ARP January 1992 5. MotivationThe 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.
6. Packet Format
Inverse ARP is an extension of the existing ARP. Therefore, it has the same format as standard ARP.
Bradley, Brown [Page 2]
RFC 1293 Inverse ARP January 1992
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.
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.
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 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.
Bradley, Brown [Page 3]
RFC 1293 Inverse ARP January 1992
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.
Bradley, Brown [Page 4]
RFC 1293 Inverse ARP January 1992
The InARP response will be completed similarly.
8. References
[1] Plummer, David C., "An Ethernet Address Resolution Protocol",
9. Security Considerations
Security issues are not addressed in this memo.
Bradley, Brown [Page 5]
RFC 1293 Inverse ARP January 1992 10. Authors' AddressesTerry Bradley Wellfleet Communications, Inc. 15 Crosby Drive Bedford, MA 01730
