1 files changed, 339 insertions, 0 deletions
diff --git a/doc/rfc/rfc1293.txt b/doc/rfc/rfc1293.txt
new file mode 100644
index 0000000..dbfe13c
--- /dev/null
+++ b/doc/rfc/rfc1293.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+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 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
+
+
+
+Bradley, Brown                                                  [Page 3]
+
+RFC 1293                      Inverse ARP                   January 1992
+
+
+   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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bradley, Brown                                                  [Page 4]
+
+RFC 1293                      Inverse ARP                   January 1992
+
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+Bradley, Brown                                                  [Page 5]
+
+RFC 1293                      Inverse ARP                   January 1992
+
+
+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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bradley, Brown                                                  [Page 6]
+
+\ No newline at end of file