InARP: Inverse Address Resolution Protocol
Extensions to ARP that discover protocol addresses from known hardware addresses.
Bradley, T. and C. Brown, "Inverse Address Resolution Protocol", RFC 1293, DOI 10.17487/RFC1293, January 1992, <https://www.rfc-editor.org/info/rfc1293>.
@misc{rfc1293,
series = {Request for Comments},
number = 1293,
howpublished = {RFC 1293},
publisher = {RFC Editor},
doi = {10.17487/RFC1293},
url = {https://www.rfc-editor.org/info/rfc1293},
author = {T. Bradley and C. Brown},
title = {{Inverse Address Resolution Protocol}},
pagetotal = 6,
year = 1992,
month = jan,
} RFC text
Contents
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
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
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
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
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.
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
AI ELI5
On this page
§1What Is Inverse ARP
Inverse Address Resolution Protocol (InARP) is an extension of the standard ARP (Address Resolution Protocol) that solves a different problem. While ARP discovers the hardware address corresponding to a protocol address, InARP discovers the protocol address corresponding to a hardware address.
InARP is particularly useful on Frame Relay networks, where stations may have a Data Link Connection Identifier (DLCI)—a Frame Relay hardware address—associated with an established Permanent Virtual Circuit (PVC), but do not know the protocol address (such as an IP address) of the station on the other side of the connection. InARP allows dynamic discovery of this protocol address, avoiding the need for manual configuration on new virtual circuits.
InARP is a way to ask another computer: "I know how to reach you, but what is your Internet address?" It works by sending a question on the wire and waiting for the answer.
§2The Problem: Frame Relay Address Discovery
Frame Relay networks identify virtual circuits using DLCIs (Data Link Connection Identifiers), which are hardware addresses. When the network announces a new virtual circuit with its DLCI, the station receiving the announcement learns of the connection but does not receive the protocol address information needed to communicate.
Alternative approaches were considered. Reverse ARP (RARP), for example, responds with the requester's protocol address, not the target's, so it was unsuitable. IP-specific mechanisms would have been limiting for networks that use multiple protocol types.
InARP solves this by allowing a Frame Relay station to directly query another station's protocol address once a new virtual circuit is established, avoiding broadcast-based methods and eliminating the need for manual static configuration. This makes virtual circuits usable immediately upon announcement.
When Frame Relay creates a new connection, the local station knows the connection ID but not the other station's IP address. InARP asks the other side: "What is your IP?"
§3Packet Format
Inverse ARP uses the same packet format as standard ARP. The packet contains eight fields:
ar$hrd (Hardware type, 16 bits), ar$pro (Protocol type, 16 bits), ar$hln (Hardware address length in bytes, 8 bits), ar$pln (Protocol address length in bytes, 8 bits), ar$op (Operation code, 16 bits), ar$sha (Source hardware address), ar$spa (Source protocol address), ar$tha (Target hardware address), and ar$tpa (Target protocol address).
The operation code distinguishes InARP messages: 8 = InARP request and 9 = InARP reply. These values were chosen to avoid conflict with other ARP extensions. Hardware and protocol type values are the same as those for standard ARP.
Address field lengths depend on the network environment. For example, on IP over Frame Relay, the hardware address length is 2 to 4 bytes (for the DLCI), and the protocol address length is 4 bytes (for a 32-bit IP address).
InARP messages look like ARP messages but use special operation codes (8 for request, 9 for reply) to identify themselves and ask for the other station's address.
§4How InARP Works
Unlike ARP, which broadcasts requests to the entire network, InARP sends requests directly to the target station because the hardware address is already known. A requesting station formats an InARP request by filling in its own source hardware and protocol addresses, the known target hardware address, and zero-fills the target protocol address field (the value being requested). The packet is encapsulated for the network and sent directly to the target.
Upon receiving an InARP request, a station may add the requester's address mapping to its ARP cache. Importantly, the receiving station may assume that any InARP request it receives is destined for it. It formats a reply using the requester's addresses as the target addresses in the response. If the station is unable or unwilling to reply, it ignores the request.
When the requesting station receives the InARP reply, it completes the address mapping and can use the provided information. Like ARP entries, information learned via InARP may be aged or invalidated over time according to protocol rules.
One station sends InARP request: "Here is my address, what is yours?" The other station receives it and sends back: "My address is X." Both stations now know each other.
§5Multiple Addresses on One Interface
Some hosts have multiple protocol addresses assigned to a single interface. When such a host receives an InARP request, it must choose which address to respond with. The receiving station should examine the protocol address in the incoming request and respond with the protocol address that corresponds to the same protocol network.
For example, if the requesting station is probing for an IP address, a multi-addressed responding station should answer with an IP address on the same subnet as the requester. If the station does not have an appropriate address for the request, it should not respond. In the IP example, if the receiving station lacks an IP address on the requested subnet, it would not reply to that InARP request.
A multi-addressed host may send multiple InARP requests, one for each of its addresses on a given interface. However, the receiving side may answer some, all, or none of the requests depending on its configuration.
If a computer has multiple addresses, it picks the one that belongs to the same group as the requester's address, so they can talk to each other.
§6InARP on Frame Relay Networks
InARP is especially useful when a new Frame Relay virtual circuit is announced. The Frame Relay station may format an InARP request addressed to the new virtual circuit. If the other side supports InARP, it returns a reply indicating the requested protocol address.
For an InARP request on Frame Relay, the operation code is 8, the hardware type is 0x000F (assigned to Frame Relay), the protocol type is the protocol being sought (such as 0x0800 for IP), and the hardware and protocol address lengths match the environment. The source hardware address is the Q.922 address of the requesting station, and the target hardware address is the Q.922 address of the newly announced virtual circuit. The target protocol address field (which the request is trying to fill in) is set to zero.
The InARP reply follows the same format, with operation code 9, and the sender's addresses filled in as the response. The RFC notes that Q.922 addresses should have the C/R, FECN, BECN, and DE bits all set to zero in InARP messages.
On Frame Relay, when a new connection appears, the station sends InARP to ask: "You just connected to me, what is your IP address?" The other station replies with its IP address.