Inverse Address Resolution Protocol
RFC 2390
| Document | Type |
RFC - Draft Standard
(September 1998; No errata)
Obsoletes RFC 1293
|
|
|---|---|---|---|
| Authors | Andy Malis , Caralyn Brown , Terry Bradley | ||
| Last updated | 2013-03-02 | ||
| Stream | IETF | ||
| Formats | plain text html pdf htmlized bibtex | ||
| Stream | WG state | (None) | |
| Document shepherd | No shepherd assigned | ||
| IESG | IESG state | RFC 2390 (Draft Standard) | |
| Consensus Boilerplate | Unknown | ||
| Telechat date | |||
| Responsible AD | (None) | ||
| Send notices to | (None) | ||
Network Working Group T. Bradley
Request for Comments: 2390 Avici Systems, Inc.
Obsoletes: 1293 C. Brown
Category: Standards Track Consultant
A. Malis
Ascend Communications, Inc.
September 1998
Inverse Address Resolution Protocol
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (1998). All Rights Reserved.
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.
This memo replaces RFC 1293. The changes from RFC 1293 are minor
changes to formalize the language, the additions of a packet diagram
and an example in section 7.2, and a new security section.
3. Conventions
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
document, are to be interpreted as described in [5].
Bradley, et. al. Standards Track [Page 1]
RFC 2390 Inverse Address Resolution Protocol September 1998
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 may be
thought of as the Frame Relay equivalent to a hardware address.
Periodically, through the exchange of signaling 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 a 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. IP
specific mechanisms were limiting since they would not allow
resolution of other protocols other than IP. For this reason, the ARP
protocol was expanded.
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 efficient than sending ARP messages
on every VC for every address the system wants to resolve and it is
more flexible than relying on static configuration.
Bradley, et. al. Standards Track [Page 2]
RFC 2390 Inverse Address Resolution Protocol September 1998
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
Show full document text