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-01.txt < prev    next >
Text File  |  1997-05-08  |  14KB  |  393 lines
  1.  
  2. Network Working Group                                         T. Bradley
  3. INTERNET-DRAFT                                       Avici Systems, Inc.
  4. Obsoletes: 1293                                                 C. Brown
  5. <draft-ietf-ion-inarp-update-01.txt>                  Fore Systems, Inc.
  6.                                                                 A. Malis
  7.                                             Cascade Communications Corp.
  8.                                                              May 7, 1997
  9.                                                 Expires November 7, 1997
  10.  
  11.                   Inverse Address Resolution Protocol
  12.  
  13. 1.  Status of this Memo
  14.  
  15.    This document is an Internet-Draft.  Internet-Drafts are working
  16.    documents of the Internet Engineering Task Force (IETF), its areas,
  17.    and its working groups.  Note that other groups may also distribute
  18.    working documents as Internet-Drafts.
  19.  
  20.    Internet-Drafts are draft documents valid for a maximum of six months
  21.    and may be updated, replaced, or obsoleted by other documents at any
  22.    time.  It is inappropriate to use Internet-Drafts as reference
  23.    material or to cite them other than as ``work in progress.''
  24.  
  25.    To learn the current status of any Internet-Draft, please check the
  26.    ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
  27.    Directories on ds.internic.net (US East Coast), nic.nordu.net
  28.    (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
  29.    Rim).
  30.  
  31.    This draft specifies an IAB standards track protocol for the Internet
  32.    community, and requests discussion and suggestions for improvements.
  33.    Please refer to the current edition of the "IAB Official Protocol
  34.    Standards" for the standardization state and status of this protocol.
  35.    Distribution of this memo is unlimited.
  36.  
  37. 2.  Abstract
  38.  
  39.    This memo describes additions to ARP that will allow a station to
  40.    request a protocol address corresponding to a given hardware address.
  41.    Specifically, this applies to Frame Relay stations that may have a
  42.    Data Link Connection Identifier (DLCI), the Frame Relay equivalent of
  43.    a hardware address, associated with an established Permanent Virtual
  44.    Circuit (PVC), but do not know the protocol address of the station on
  45.    the other side of this connection.  It will also apply to other
  46.    networks with similar circumstances.
  47.  
  48. 3.  Conventions
  49.  
  50.  
  51.  
  52.  
  53. Bradley, Brown, Malis   Expires November 7, 1997                [Page 1]
  54.  
  55. INTERNET-DRAFT                Inverse ARP                    May 7, 1997
  56.  
  57.  
  58.    The following language conventions are used in the items of
  59.    specification in this document:
  60.  
  61.      o Must, Will, Shall or Mandatory -- the item is an absolute
  62.        requirement of the specification.
  63.  
  64.      o Should or Recommended -- the item should generally be
  65.        followed for all but exceptional circumstances.
  66.  
  67.      o May or Optional -- the item is truly optional and may be
  68.        followed or ignored according to the needs of the
  69.        implementor.
  70.  
  71. 4.  Introduction
  72.  
  73.    This document will rely heavily on Frame Relay as an example of how
  74.    the Inverse Address Resolution Protocol (InARP) can be useful. It is
  75.    not, however, intended that InARP be used exclusively with Frame
  76.    Relay.  InARP may be used in any network that provides destination
  77.    hardware addresses without indicating corresponding protocol
  78.    addresses.
  79.  
  80. 5.  Motivation
  81.  
  82.    The motivation for the development of Inverse ARP is a result of the
  83.    desire to make dynamic address resolution within Frame Relay both
  84.    possible and efficient.  Permanent virtual circuits (PVCs) and
  85.    eventually switched virtual circuits (SVCs) are identified by a Data
  86.    Link Connection Identifier (DLCI).  These DLCIs define a single
  87.    virtual connection through the wide area network (WAN) and may be
  88.    thought of as the Frame Relay equivalent to a hardware address.
  89.    Periodically, through the exchange of signaling messages, a network
  90.    may announce a new virtual circuit with its corresponding DLCI.
  91.    Unfortunately, protocol addressing is not included in the
  92.    announcement.  The station receiving such an indication will learn of
  93.    the new connection, but will not be able to address the other side.
  94.    Without a new configuration or a mechanism for discovering the
  95.    protocol address of the other side, this new virtual circuit is
  96.    unusable.
  97.  
  98.    Other resolution methods were considered to solve the problems, but
  99.    were rejected.  Reverse ARP [4], for example, seemed like a good
  100.    candidate, but the response to a request is the protocol address of
  101.    the requesting station, not the station receiving the request.  IP
  102.    specific mechanisms were limiting since they would not allow
  103.    resolution of other protocols other than IP. For this reason, the ARP
  104.    protocol was expanded.
  105.  
  106.  
  107.  
  108.  
  109. Bradley, Brown, Malis   Expires November 7, 1997                [Page 2]
  110.  
  111. INTERNET-DRAFT                Inverse ARP                    May 7, 1997
  112.  
  113.  
  114.    Inverse Address Resolution Protocol (InARP) will allow a Frame Relay
  115.    station to discover the protocol address of a station associated with
  116.    the virtual circuit.  It is more efficient than sending ARP messages
  117.    on every VC for every address the system wants to resolve and it is
  118.    more flexible than relying on static configuration.
  119.  
  120. 6.  Packet Format
  121.  
  122.    Inverse ARP is an extension of the existing ARP.  Therefore, it has
  123.    the same format as standard ARP.
  124.  
  125.       ar$hrd   16 bits         Hardware type
  126.       ar$pro   16 bits         Protocol type
  127.       ar$hln    8 bits         Byte length of each hardware address (n)
  128.       ar$pln    8 bits         Byte length of each protocol address (m)
  129.       ar$op    16 bits         Operation code
  130.       ar$sha    nbytes         source hardware address
  131.       ar$spa    mbytes         source protocol address
  132.       ar$tha    nbytes         target hardware address
  133.       ar$tpa    mbytes         target protocol address
  134.  
  135.    Possible values for hardware and protocol types are the same as those
  136.    for ARP and may be found in the current Assigned Numbers RFC [2].
  137.  
  138.    Length of the hardware and protocol address are dependent on the
  139.    environment in which InARP is running.  For example, if IP is running
  140.    over Frame Relay, the hardware address length is either 2, 3, or 4,
  141.    and the protocol address length is 4.
  142.  
  143.    The operation code indicates the type of message, request or reply.
  144.  
  145.       InARP request  = 8
  146.       InARP reply = 9
  147.  
  148.    These values were chosen so as not to conflict with other ARP
  149.    extensions.
  150.  
  151. 7.  Protocol Operation
  152.  
  153.    Basic InARP operates essentially the same as ARP with the exception
  154.    that InARP does not broadcast requests.  This is because the hardware
  155.    address of the destination station is already known.
  156.  
  157.    When an interface supporting InARP becomes active, it should initiate
  158.    the InARP protocol and format InARP requests for each active PVC for
  159.    which InARP is active.  To do this, a requesting station simply
  160.    formats a request by inserting its source hardware, source protocol
  161.    addresses and the known target hardware address.  It then zero fills
  162.  
  163.  
  164.  
  165. Bradley, Brown, Malis   Expires November 7, 1997                [Page 3]
  166.  
  167. INTERNET-DRAFT                Inverse ARP                    May 7, 1997
  168.  
  169.  
  170.    the target protocol address field.  Finally, it will encapsulate the
  171.    packet for the specific network and send it directly to the target
  172.    station.
  173.  
  174.    Upon receiving an InARP request, a station may put the requester's
  175.    protocol address/hardware address mapping into its ARP cache as it
  176.    would any ARP request.  Unlike other ARP requests, however, the
  177.    receiving station may assume that any InARP request it receives is
  178.    destined for it.  For every InARP request, the receiving station
  179.    should format a proper reply using the source addresses from the
  180.    request as the target addresses of the reply.  If the station is
  181.    unable or unwilling to reply, it ignores the request.
  182.  
  183.    When the requesting station receives the InARP reply, it may complete
  184.    the ARP table entry and use the provided address information.  Note:
  185.    as with ARP, information learned via InARP may be aged or invalidated
  186.    under certain circumstances.
  187.  
  188. 7.1.  Operation with Multi-Addressed Hosts
  189.  
  190.    In the context of this discussion, a multi-addressed host will refer
  191.    to a host that has multiple protocol addresses assigned to a single
  192.    interface.  If such a station receives an InARP request, it must
  193.    choose one address with which to respond. To make such a selection,
  194.    the receiving station must first look at the protocol address of the
  195.    requesting station, and then respond with the protocol address
  196.    corresponding to the network of the requester.  For example, if the
  197.    requesting station is probing for an IP address, the responding
  198.    multi-addressed station should respond with an IP address which
  199.    corresponds to the same subnet as the requesting station.  If the
  200.    station does not have an address that is appropriate for the request
  201.    it should not respond.  In the IP example, if the receiving station
  202.    does not have an IP address assigned to the interface that is a part
  203.    of the requested subnet, the receiving station would not respond.
  204.  
  205.    A multi-addressed host should send an InARP request for each of the
  206.    addresses defined for the given interface.  It should be noted,
  207.    however, that the receiving side may answer some or none of the
  208.    requests depending on its configuration.
  209.  
  210. 7.2.  Protocol Operation Within Frame Relay
  211.  
  212.    One case where Inverse ARP can be used is on a frame relay interface
  213.    which supports signaling of DLCIs via a data link management
  214.    interface. An InARP equipped station connected to such an interface
  215.    will format an InARP request and address it to the new virtual
  216.    circuit.  If the other side supports InARP, it may return a reply
  217.    indicating the protocol address requested.
  218.  
  219.  
  220.  
  221. Bradley, Brown, Malis   Expires November 7, 1997                [Page 4]
  222.  
  223. INTERNET-DRAFT                Inverse ARP                    May 7, 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   Expires November 7, 1997                [Page 5]
  278.  
  279. INTERNET-DRAFT                Inverse ARP                    May 7, 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, D., "An Ethernet Address Resolution Protocol - or -
  290.         Converting Network Protocol Addresses to 48.bit Ethernet Address
  291.         for Transmission on Ethernet Hardware", STD 37, RFC 826, MIT,
  292.         November 1982.
  293.  
  294.    [2] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
  295.         USC/Information Sciences Institute, October 1994
  296.  
  297.    [3] Bradley, T.,  Brown, C., Malis, A., "Multiprotocol Interconnect 
  298.        over Frame Relay", RFC 1490, July 1993.
  299.  
  300.    [4] Finlayson, R., Mann, R., Mogul, J., and M. Theimer, "A Reverse
  301.         Address Resolution Protocol", STD 38, RFC 903, Stanford
  302.         University, June 1984.
  303.  
  304. 9.  Security Considerations
  305.  
  306.    Security issues are not addressed in this memo.
  307.  
  308. 10.  Authors' Addresses
  309.  
  310.    Terry Bradley
  311.    Avici Systems, Inc.
  312.    12 Elizabeth Drive
  313.    Chelmsford, MA  01824
  314.    Phone:  (508) 250-3344
  315.    Email: tbradley@avici.com
  316.  
  317.    Caralyn Brown
  318.    FORE Systems, Inc.
  319.    1 Corporate Drive
  320.    Andover, MA 01810
  321.    Phone:  (508) 689-2400 x133
  322.    Email:  cbrown@fore.com
  323.  
  324.    Andrew Malis
  325.    Cascade Communications Corp.
  326.    5 Carlisle Road
  327.    Westford, MA  01886
  328.    Phone: (508) 952-7414
  329.    Email:  malis@casc.com
  330.  
  331.  
  332.  
  333. Bradley, Brown, Malis   Expires November 7, 1997                [Page 6]
  334.  
  335. INTERNET-DRAFT                Inverse ARP                    May 7, 1997
  336.  
  337.  
  338.  
  339.  
  340.  
  341.  
  342.  
  343.  
  344.  
  345.  
  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   Expires November 7, 1997                [Page 7]
  390.  
  391.  
  392.  
  393.