RFC 1293 (rfc1293) - Page 2 of 6
Inverse Address Resolution Protocol
Alternative Format: Original Text Document
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