Internet Draft

Network Working Group                                         T. Bradley
INTERNET-DRAFT                                       Avici Systems, Inc.
Obsoletes: 1293                                                 C. Brown
<draft-ietf-ion-inarp-update-01.txt>                  Fore Systems, Inc.
                                                                A. Malis
                                            Cascade Communications Corp.
                                                             May 7, 1997
                                                Expires November 7, 1997

                  Inverse Address Resolution Protocol

1.  Status of this Memo

   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as ``work in progress.''

   To learn the current status of any Internet-Draft, please check the
   ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
   Directories on ds.internic.net (US East Coast), nic.nordu.net
   (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
   Rim).

   This draft 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




Bradley, Brown, Malis   Expires November 7, 1997                [Page 1]

INTERNET-DRAFT                Inverse ARP                    May 7, 1997


   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
   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.




Bradley, Brown, Malis   Expires November 7, 1997                [Page 2]

INTERNET-DRAFT                Inverse ARP                    May 7, 1997


   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.

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

   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 either 2, 3, or 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.

   When an interface supporting InARP becomes active, it should initiate
   the InARP protocol and format InARP requests for each active PVC for
   which InARP is active.  To do this, a requesting station simply
   formats a request by inserting its source hardware, source protocol
   addresses and the known target hardware address.  It then zero fills



Bradley, Brown, Malis   Expires November 7, 1997                [Page 3]

INTERNET-DRAFT                Inverse ARP                    May 7, 1997


   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
   should 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
   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 should 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 on a frame relay interface
   which supports signaling of DLCIs via a data link management
   interface. An InARP equipped station connected to such an interface
   will format an InARP request and address it to the new virtual
   circuit.  If the other side supports InARP, it may return a reply
   indicating the protocol address requested.



Bradley, Brown, Malis   Expires November 7, 1997                [Page 4]

INTERNET-DRAFT                Inverse ARP                    May 7, 1997


   In a frame relay environment, InARP packets are encapsulated using
   the NLPID/SNAP format defined in [3] which indicates the ARP
   protocol.  Specifically, the packet encapsulation will be as follows:

               +----------+----------+
               |   Q.922 address     |
               +----------+----------+
               |ctrl 0x03 | pad 00   |
               +----------+----------+
               |nlpid 0x80| oui 0x00 |
               +----------+          +
               | oui (cont) 0x00 00  |
               +----------+----------+
               | pid 0x08 06         |
               +----------+----------+
               |          .          |
               |          .          |


   The format for an InARP request itself is defined by the following:

      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 is being requested

   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



Bradley, Brown, Malis   Expires November 7, 1997                [Page 5]

INTERNET-DRAFT                Inverse ARP                    May 7, 1997


   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 [3].

8.  References

   [1] Plummer, D., "An Ethernet Address Resolution Protocol - or -
        Converting Network Protocol Addresses to 48.bit Ethernet Address
        for Transmission on Ethernet Hardware", STD 37, RFC 826, MIT,
        November 1982.

   [2] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
        USC/Information Sciences Institute, October 1994

   [3] Bradley, T.,  Brown, C., Malis, A., "Multiprotocol Interconnect 
       over Frame Relay", RFC 1490, July 1993.

   [4] Finlayson, R., Mann, R., Mogul, J., and M. Theimer, "A Reverse
        Address Resolution Protocol", STD 38, RFC 903, Stanford
        University, June 1984.

9.  Security Considerations

   Security issues are not addressed in this memo.

10.  Authors' Addresses

   Terry Bradley
   Avici Systems, Inc.
   12 Elizabeth Drive
   Chelmsford, MA  01824
   Phone:  (508) 250-3344
   Email: tbradley@avici.com

   Caralyn Brown
   FORE Systems, Inc.
   1 Corporate Drive
   Andover, MA 01810
   Phone:  (508) 689-2400 x133
   Email:  cbrown@fore.com

   Andrew Malis
   Cascade Communications Corp.
   5 Carlisle Road
   Westford, MA  01886
   Phone: (508) 952-7414
   Email:  malis@casc.com



Bradley, Brown, Malis   Expires November 7, 1997                [Page 6]

INTERNET-DRAFT                Inverse ARP                    May 7, 1997





















































Bradley, Brown, Malis   Expires November 7, 1997                [Page 7]