Movatterモバイル変換

Network Working Group                                         T. BradleyRequest for Comments: 1293                                      C. Brown                                          Wellfleet Communications, Inc.                                                            January 1992Inverse Address Resolution Protocol1.  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 protocolBradley, 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 addressBradley, 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 theBradley, 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 forBradley, 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 insection 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 199210.  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.comBradley, Brown                                                  [Page 6]