Inverse Address Resolution Protocol
RFC 1293
Document | Type |
RFC - Proposed Standard
(January 1992; No errata)
Obsoleted by RFC 2390
|
|
---|---|---|---|
Authors | Terry Bradley , Caralyn Brown | ||
Last updated | 2013-03-02 | ||
Stream | Internent Engineering Task Force (IETF) | ||
Formats | plain text html pdf htmlized (tools) htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 1293 (Proposed Standard) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) |
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 theShow full document text