home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_i / draft-ietf-ion-inarp-update-00.txt < prev    next >
Text File  |  1996-11-19  |  13KB  |  391 lines
  1.  
  2. Network Working Group                                         T. Bradley
  3. INTERNET-DRAFT                            StarBurst Communications Corp.
  4. Obsoletes: 1293                                                 C. Brown
  5. <draft-ietf-ion-inarp-update-00.txt>                Cadia Networks, Inc.
  6.                                                                 A. Malis
  7.                                                             Ascom Nexion
  8.                                                         Expires May 1997
  9.  
  10.                   Inverse Address Resolution Protocol
  11.  
  12. 1.  Status of this Memo
  13.  
  14.    This document is an Internet-Draft.  Internet-Drafts are working
  15.    documents of the Internet Engineering Task Force (IETF), its areas,
  16.    and its working groups.  Note that other groups may also distribute
  17.    working documents as Internet-Drafts.
  18.  
  19.    Internet-Drafts are draft documents valid for a maximum of six months
  20.    nand may be updated, replaced, or obsoleted by other documents at any
  21.    time.  It is inappropriate to use Internet-Drafts as reference
  22.    material or to cite them other than as ``work in progress.''
  23.  
  24.    To learn the current status of any Internet-Draft, please check the
  25.    ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
  26.    Directories on ds.internic.net (US East Coast), nic.nordu.net
  27.    (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
  28.    Rim).
  29.  
  30. 2.  Abstract
  31.  
  32.    This memo describes additions to ARP that will allow a station to
  33.    request a protocol address corresponding to a given hardware address.
  34.    Specifically, this applies to Frame Relay stations that may have a
  35.    Data Link Connection Identifier (DLCI), the Frame Relay equivalent of
  36.    a hardware address, associated with an established Permanent Virtual
  37.    Circuit (PVC), but do not know the protocol address of the station on
  38.    the other side of this connection.  It will also apply to other
  39.    networks with similar circumstances.
  40.  
  41. 3.  Conventions
  42.  
  43.    The following language conventions are used in the items of
  44.    specification in this document:
  45.  
  46.      o Must, Will, Shall or Mandatory -- the item is an absolute
  47.        requirement of the specification.
  48.  
  49.      o Should or Recommended -- the item should generally be
  50.  
  51.  
  52.  
  53. Bradley, Brown, Malis                                           [Page 1]
  54.  
  55. INTERNET-DRAFT                Inverse ARP               Expires May 1997
  56.  
  57.  
  58.        followed for all but exceptional circumstances.
  59.  
  60.      o May or Optional -- the item is truly optional and may be
  61.        followed or ignored according to the needs of the
  62.        implementor.
  63.  
  64. 4.  Introduction
  65.  
  66.    This document will rely heavily on Frame Relay as an example of how
  67.    the Inverse Address Resolution Protocol (InARP) can be useful. It is
  68.    not, however, intended that InARP be used exclusively with Frame
  69.    Relay.  InARP may be used in any network that provides destination
  70.    hardware addresses without indicating corresponding protocol
  71.    addresses.
  72.  
  73. 5.  Motivation
  74.  
  75.    The motivation for the development of Inverse ARP is a result of the
  76.    desire to make dynamic address resolution within Frame Relay both
  77.    possible and efficient.  Permanent virtual circuits (PVCs) and
  78.    eventually switched virtual circuits (SVCs) are identified by a Data
  79.    Link Connection Identifier (DLCI).  These DLCIs define a single
  80.    virtual connection through the wide area network (WAN) and may be
  81.    thought of as the Frame Relay equivalent to a hardware address.
  82.    Periodically, through the exchange of signaling messages, a network
  83.    may announce a new virtual circuit with its corresponding DLCI.
  84.    Unfortunately, protocol addressing is not included in the
  85.    announcement.  The station receiving such an indication will learn of
  86.    the new connection, but will not be able to address the other side.
  87.    Without a new configuration or a mechanism for discovering the
  88.    protocol address of the other side, this new virtual circuit is
  89.    unusable.
  90.  
  91.    Other resolution methods were considered to solve the problems, but
  92.    were rejected.  Reverse ARP [4], for example, seemed like a good
  93.    candidate, but the response to a request is the protocol address of
  94.    the requesting station, not the station receiving the request.  IP
  95.    specific mechanisms were limiting since they would not allow
  96.    resolution of other protocols other than IP. For this reason, the ARP
  97.    protocol was expanded.
  98.  
  99.    Inverse Address Resolution Protocol (InARP) will allow a Frame Relay
  100.    station to discover the protocol address of a station associated with
  101.    the virtual circuit.  It is more efficient than sending ARP messages
  102.    on every VC for every address the system wants to resolve and it is
  103.    more flexible than relying on static configuration.
  104.  
  105.  
  106.  
  107.  
  108.  
  109. Bradley, Brown, Malis                                           [Page 2]
  110.  
  111. INTERNET-DRAFT                Inverse ARP               Expires May 1997
  112.  
  113.  
  114. 6.  Packet Format
  115.  
  116.    Inverse ARP is an extension of the existing ARP.  Therefore, it has
  117.    the same format as standard ARP.
  118.  
  119.       ar$hrd   16 bits         Hardware type
  120.       ar$pro   16 bits         Protocol type
  121.       ar$hln    8 bits         Byte length of each hardware address (n)
  122.       ar$pln    8 bits         Byte length of each protocol address (m)
  123.       ar$op    16 bits         Operation code
  124.       ar$sha    nbytes         source hardware address
  125.       ar$spa    mbytes         source protocol address
  126.       ar$tha    nbytes         target hardware address
  127.       ar$tpa    mbytes         target protocol address
  128.  
  129.    Possible values for hardware and protocol types are the same as those
  130.    for ARP and may be found in the current Assigned Numbers RFC [2].
  131.  
  132.    Length of the hardware and protocol address are dependent on the
  133.    environment in which InARP is running.  For example, if IP is running
  134.    over Frame Relay, the hardware address length is either 2, 3, or 4,
  135.    and the protocol address length is 4.
  136.  
  137.    The operation code indicates the type of message, request or reply.
  138.  
  139.       InARP request  = 8
  140.       InARP reply = 9
  141.  
  142.    These values were chosen so as not to conflict with other ARP
  143.    extensions.
  144.  
  145. 7.  Protocol Operation
  146.  
  147.    Basic InARP operates essentially the same as ARP with the exception
  148.    that InARP does not broadcast requests.  This is because the hardware
  149.    address of the destination station is already known.
  150.  
  151.    When an interface supporting InARP becomes active, it should initiate
  152.    the InARP protocol and format InARP requests for each active PVC for
  153.    which InARP is active.  To do this, a requesting station simply
  154.    formats a request by inserting its source hardware, source protocol
  155.    addresses and the known target hardware address.  It then zero fills
  156.    the target protocol address field.  Finally, it will encapsulate the
  157.    packet for the specific network and send it directly to the target
  158.    station.
  159.  
  160.    Upon receiving an InARP request, a station may put the requester's
  161.    protocol address/hardware address mapping into its ARP cache as it
  162.  
  163.  
  164.  
  165. Bradley, Brown, Malis                                           [Page 3]
  166.  
  167. INTERNET-DRAFT                Inverse ARP               Expires May 1997
  168.  
  169.  
  170.    would any ARP request.  Unlike other ARP requests, however, the
  171.    receiving station may assume that any InARP request it receives is
  172.    destined for it.  For every InARP request, the receiving station
  173.    should format a proper reply using the source addresses from the
  174.    request as the target addresses of the reply.  If the station is
  175.    unable or unwilling to reply, it ignores the request.
  176.  
  177.    When the requesting station receives the InARP reply, it may complete
  178.    the ARP table entry and use the provided address information.  Note:
  179.    as with ARP, information learned via InARP may be aged or invalidated
  180.    under certain circumstances.
  181.  
  182. 7.1.  Operation with Multi-Addressed Hosts
  183.  
  184.    In the context of this discussion, a multi-addressed host will refer
  185.    to a host that has multiple protocol addresses assigned to a single
  186.    interface.  If such a station receives an InARP request, it must
  187.    choose one address with which to respond. To make such a selection,
  188.    the receiving station must first look at the protocol address of the
  189.    requesting station, and then respond with the protocol address
  190.    corresponding to the network of the requester.  For example, if the
  191.    requesting station is probing for an IP address, the responding
  192.    multi-addressed station should respond with an IP address which
  193.    corresponds to the same subnet as the requesting station.  If the
  194.    station does not have an address that is appropriate for the request
  195.    it should not respond.  In the IP example, if the receiving station
  196.    does not have an IP address assigned to the interface that is a part
  197.    of the requested subnet, the receiving station would not respond.
  198.  
  199.    A multi-addressed host should send an InARP request for each of the
  200.    addresses defined for the given interface.  It should be noted,
  201.    however, that the receiving side may answer some or none of the
  202.    requests depending on its configuration.
  203.  
  204. 7.2.  Protocol Operation Within Frame Relay
  205.  
  206.    One case where Inverse ARP can be used is on a frame relay interface
  207.    which supports signaling of DLCIs via a data link management
  208.    interface. An InARP equipped station connected to such an interface
  209.    will format an InARP request and address it to the new virtual
  210.    circuit.  If the other side supports InARP, it may return a reply
  211.    indicating the protocol address requested.
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221. Bradley, Brown, Malis                                           [Page 4]
  222.  
  223. INTERNET-DRAFT                Inverse ARP               Expires May 1997
  224.  
  225.  
  226.    In a frame relay environment, InARP packets are encapsulated using
  227.    the NLPID/SNAP format defined in [3] which indicates the ARP
  228.    protocol.  Specifically, the packet encapsulation will be as follows:
  229.  
  230.                +----------+----------+
  231.                |   Q.922 address     |
  232.                +----------+----------+
  233.                |ctrl 0x03 | pad 00   |
  234.                +----------+----------+
  235.                |nlpid 0x80| oui 0x00 |
  236.                +----------+          +
  237.                | oui (cont) 0x00 00  |
  238.                +----------+----------+
  239.                | pid 0x08 06         |
  240.                +----------+----------+
  241.                |          .          |
  242.                |          .          |
  243.  
  244.  
  245.    The format for an InARP request itself is defined by the following:
  246.  
  247.       ar$hrd - 0x000F the value assigned to Frame Relay
  248.       ar$pro - protocol type for which you are searching
  249.                   (i.e.  IP = 0x0800)
  250.       ar$hln - 2,3, or 4 byte addressing length
  251.       ar$pln - byte length of protocol address for which you
  252.                   are searching (for IP = 4)
  253.       ar$op  - 8; InARP request
  254.       ar$sha - Q.922 address of requesting station
  255.       ar$spa - protocol address of requesting station
  256.       ar$tha - Q.922 addressed of newly announced virtual circuit
  257.       ar$tpa - 0; This is what is being requested
  258.  
  259.    The InARP response will be completed similarly.
  260.  
  261.       ar$hrd - 0x000F the value assigned to Frame Relay
  262.       ar$pro - protocol type for which you are searching
  263.                  (i.e.  IP = 0x0800)
  264.       ar$hln - 2,3, or 4 byte addressing length
  265.       ar$pln - byte length of protocol address for which you
  266.                  are searching (for IP = 4)
  267.       ar$op  - 9; InARP response
  268.       ar$sha - Q.922 address of responding station
  269.       ar$spa - protocol address requested
  270.       ar$tha - Q.922 address of requesting station
  271.       ar$tpa - protocol address of requesting station
  272.  
  273.    Note that the Q.922 addresses specified have the C/R, FECN, BECN, and
  274.  
  275.  
  276.  
  277. Bradley, Brown, Malis                                           [Page 5]
  278.  
  279. INTERNET-DRAFT                Inverse ARP               Expires May 1997
  280.  
  281.  
  282.    DE bits set to zero.
  283.  
  284.    Procedures for using InARP over a Frame Relay network are identical
  285.    to those for using ARP and RARP discussed in [3].
  286.  
  287. 8.  References
  288.  
  289.    [1]  Plummer, David C., "An Ethernet Address Resolution Protocol",
  290.         RFC 826, November 1982.
  291.  
  292.    [2]  Reynolds, J. and Postel, J., "Assigned Numbers", RFC 1700,
  293.         October 1994.
  294.  
  295.    [3]  Brown, C., Malis, A., "Multiprotocol Interconnect over Frame
  296.         Relay", RFC 1490, July 1993.
  297.  
  298.    [4]  Finlayson, Mann, Mogul, Theimer, "A Reverse Address Resolution
  299.         Protocol", RFC 903, June 1984.
  300.  
  301. 9.  Security Considerations
  302.  
  303.    Security issues are not addressed in this memo.
  304.  
  305. 10.  Authors' Addresses
  306.  
  307.       Terry Bradley
  308.       StarBurst Communications Corporation
  309.       150 Baker Avenue,
  310.       Concord, MA  01742
  311.  
  312.       Phone:  (508) 287-5560
  313.  
  314.       Email: tbradley@starburstcom.com
  315.  
  316.       Caralyn Brown
  317.       Cadia Networks, Inc.
  318.       1 Corporate Drive
  319.       Andover, MA 01810
  320.  
  321.       Phone:  (508) 689-2400 x133
  322.  
  323.       Email:  cbrown@cadia.com
  324.  
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333. Bradley, Brown, Malis                                           [Page 6]
  334.  
  335. INTERNET-DRAFT                Inverse ARP               Expires May 1997
  336.  
  337.  
  338.       Andrew Malis
  339.       Ascom Nexion
  340.       289 Great Rd.
  341.       Acton, MA  01720
  342.  
  343.       Phone:  (508) 266-4522
  344.  
  345.       Email:  malis@nexen.com
  346.  
  347.  
  348.  
  349.  
  350.  
  351.  
  352.  
  353.  
  354.  
  355.  
  356.  
  357.  
  358.  
  359.  
  360.  
  361.  
  362.  
  363.  
  364.  
  365.  
  366.  
  367.  
  368.  
  369.  
  370.  
  371.  
  372.  
  373.  
  374.  
  375.  
  376.  
  377.  
  378.  
  379.  
  380.  
  381.  
  382.  
  383.  
  384.  
  385.  
  386.  
  387.  
  388.  
  389. Bradley, Brown, Malis                                           [Page 7]
  390.  
  391.