home *** CD-ROM | disk | FTP | other *** search
/ The Hacker's Encyclopedia 1998 / hackers_encyclopedia.iso / rfc / 3 / rfc1735.txt < prev    next >
Encoding:
Text File  |  2003-06-11  |  23.9 KB  |  620 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                        J. Heinanen
  8. Request for Comments: 1735                               Telecom Finland
  9. Category: Experimental                                       R. Govindan
  10.                                                                      ISI
  11.                                                            December 1994
  12.  
  13.  
  14.                 NBMA Address Resolution Protocol (NARP)
  15.  
  16. Status of this Memo
  17.  
  18.    This memo defines an Experimental Protocol for the Internet
  19.    community.  This memo does not specify an Internet standard of any
  20.    kind.  Discussion and suggestions for improvement are requested.
  21.    Distribution of this memo is unlimited.
  22.  
  23. IESG Note:
  24.  
  25.    Note that the work contained in this memo does not describe an
  26.    Internet standard.  This work represents an early stage in the
  27.    ongoing efforts to resolve direct communication over NBMA subnets.
  28.    It is a suitable experimental protocol for early deployment.  It is
  29.    expect that it will be superceded by other work being developed
  30.    within the IETF.
  31.  
  32. Abstract
  33.  
  34.    This document describes the NBMA Address Resolution Protocol (NARP).
  35.    NARP can be used by a source terminal (host or router) connected to a
  36.    Non-Broadcast, Multi-Access link layer (NBMA) network to find out the
  37.    NBMA addresses of the a destination terminal provided that the
  38.    destination terminal is connected to the same NBMA network.  Although
  39.    this document focuses on NARP in the context of IP, the technique is
  40.    applicable to other network layer protocols as well.  This RFC is a
  41.    product of the Routing over Large Clouds Working Group of the IETF.
  42.  
  43. 1. Introduction
  44.  
  45.    The NBMA Address Resolution Protocol (NARP) allows a source terminal
  46.    (a host or router), wishing to communicate over a Non-Broadcast,
  47.    Multi-Access link layer (NBMA) network, to find out the NBMA
  48.    addresses of a destination terminal if the destination terminal is
  49.    connected to the same NBMA network as the source.
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Heinanen & Govindan                                             [Page 1]
  59.  
  60. RFC 1735                    NBMA ARP (NARP)                December 1994
  61.  
  62.  
  63.    A conventional address resolution protocol, such as ARP [1, 2] for
  64.    IP, may not be sufficient to resolve the NBMA address of the
  65.    destination terminal, since it only applies to terminals belonging to
  66.    the same IP subnetwork, whereas an NBMA network can consist of
  67.    multiple logically independent IP subnets (LISs, [3]).
  68.  
  69.    Once the NBMA address of the destination terminal is resolved, the
  70.    source may either start sending IP packets to the destination (in a
  71.    connectionless NBMA network such as SMDS) or may first establish a
  72.    connection to the destination with the desired bandwidth and QOS
  73.    characteristics (in a connection oriented NBMA network such as ATM).
  74.  
  75.    An NBMA network can be non-broadcast either because it technically
  76.    doesn't support broadcasting (e.g., an X.25 network) or because
  77.    broadcasting is not feasible for one reason or another (e.g., an SMDS
  78.    broadcast group or an extended Ethernet would be too large).
  79.  
  80. 2. Protocol Overview
  81.  
  82.    In this section, we briefly describe how a source S uses NARP to
  83.    determine the NBMA address of a destination D or to find out that
  84.    such an address doesn't exist.  S first checks if the destination
  85.    terminal belongs to the same IP subnetwork as S itself.  If so, S
  86.    resolves the NBMA address of D using conventional means, such as ARP
  87.    [1, 2] or preconfigured tables.  If D resides in another subnetwork,
  88.    S formulates a NARP request containing the source and destination IP
  89.    addresses.  S then forwards the request to an entity called the "NBMA
  90.    ARP Server" (NAS).
  91.  
  92.    For administrative and policy reasons, a physical NBMA network may be
  93.    partitioned into several disjoint logical NBMA networks.  NASs
  94.    cooperatively resolve the NBMA next hop within their logical NBMA
  95.    network.  In the following we'll always use the term "NBMA network"
  96.    to mean a logical NBMA network.  If S is connected to several NBMA
  97.    networks, it should have at least one NAS in each of them.  In order
  98.    to know which NAS(s) to query for which destination addresses, a
  99.    multi-homed S should also be configured to receive reachability
  100.    information from its NASs.
  101.  
  102.    Each NAS "serves" a pre-configured set of terminals and peers with a
  103.    pre-configured set of NASs, which all belong to the same NBMA
  104.    network.  A NAS may also peer with routers outside the served NBMA.
  105.    A NAS exchanges reachability information with its peers (and possibly
  106.    with the terminals it serves) using regular routing protocols.  This
  107.    exchange is used to construct a forwarding table in every NAS.  The
  108.    forwarding table determines the next hop NAS towards the NARP
  109.    request's destination or a next hop router outside the NBMA.
  110.  
  111.  
  112.  
  113.  
  114. Heinanen & Govindan                                             [Page 2]
  115.  
  116. RFC 1735                    NBMA ARP (NARP)                December 1994
  117.  
  118.  
  119.    After receiving a NARP request, the NAS checks if it "serves" D.  If
  120.    so, the NAS resolves D's NBMA address, using mechanisms beyond the
  121.    scope of this document (examples of such mechanisms include ARP [1,
  122.    2] and pre-configured tables).  The NAS then either forwards the NARP
  123.    request to D or generates a positive NARP reply on its behalf.  The
  124.    reply contains D's IP and NBMA address and is sent back to S.  NARP
  125.    replies usually traverse the same sequence of NASs as the NARP
  126.    request (in reverse order, of course).
  127.  
  128.    If the NAS does not serve D, it extracts from its forwarding table
  129.    the next hop towards D.  If the next hop is a peer NAS, it forwards
  130.    the NARP request to the next hop.  If the next hop is a peer router
  131.    outside the served NBMA or if no such next hop entry is found, the
  132.    NAS generates a negative NARP reply.
  133.  
  134.    A NAS receiving a NARP reply may cache the NBMA address information
  135.    contained therein.  If a subsequent NARP request for the same target
  136.    address does not desire an authorative reply, a caching NAS can then
  137.    respond with the cached non-authoritative NBMA address or with cached
  138.    negative information.  A well behaving terminal should always first
  139.    accept a non-authoritative reply.  Only if communication attempt
  140.    based on the non-authoritative information fails, the terminal can
  141.    choose to issue another request this time asking for an authoritative
  142.    reply.
  143.  
  144.    NARP requests and replies never cross the borders of an NBMA network.
  145.    Thus, IP traffic out off and into an NBMA network always traverses an
  146.    IP router at its border.  Network layer filtering can then be
  147.    implemented at these border routers.
  148.  
  149. 3. Configuration
  150.  
  151.    Terminals
  152.  
  153.       To participate in NARP, a terminal connected to an NBMA network
  154.       should to be configured with the IP address(es) of its NAS(s).  If
  155.       the terminal is attached to several NBMA networks, it should also
  156.       be configured to receive reachability information from its NAS(s)
  157.       so that it can determine, which IP destinations are reachable
  158.       through which NBMA networks.
  159.  
  160.    NBMA ARP Servers
  161.  
  162.       A NAS is configured with a set of IP address prefixes that
  163.       correspond to the IP addresses of the terminals it is serving.
  164.       Moreover, the NAS must be configured to exchange reachability
  165.       information with its peer NASs (if any).  In addition, the NAS may
  166.       be configured to exchange reachability information with routers
  167.  
  168.  
  169.  
  170. Heinanen & Govindan                                             [Page 3]
  171.  
  172. RFC 1735                    NBMA ARP (NARP)                December 1994
  173.  
  174.  
  175.       outside the served NBMA.  And finally, if a served terminal is
  176.       attached to several NBMA networks, the NAS may need to be
  177.       configured to send reachability information to such a terminal.
  178.  
  179. 4. Packet Formats
  180.  
  181.    NARP requests and replies are carried in IP packets as protocol type
  182.    54.  This section describes the packet formats of NARP requests and
  183.    replies:
  184.  
  185.    NARP Request
  186.  
  187.        0                   1                   2                   3
  188.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  189.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  190.       |    Version    |   Hop Count   |          Checksum             |
  191.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  192.       |     Type      |    Code       |           Unused              |
  193.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  194.       |                    Destination IP address                     |
  195.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  196.       |                      Source IP address                        |
  197.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  198.       | NBMA length   |                NBMA address                   |
  199.       +-+-+-+-+-+-+-+-+                                               |
  200.       |                  (variable length)                            |
  201.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  202.  
  203.    Version
  204.      The NARP version number.  Currently this value is 1.
  205.  
  206.    Hop Count
  207.      The Hop count indicates the maximum number of NASs that a request
  208.      or reply is allowed to traverse before being discarded.
  209.  
  210.    Checksum
  211.      The standard IP checksum over the entire NARP packet (starting with
  212.      the fixed header).
  213.  
  214.    Type
  215.      The NARP packet type.  The NARP Request has a Type code 1.
  216.  
  217.    Code
  218.      A response to an NARP request may contain cached information. If an
  219.      authoritative answer is desired, then code 2 (NARP Request for
  220.      Authoritative Information) should be used. Otherwise, a code value
  221.      of 1 (NARP Request) should be used.
  222.  
  223.  
  224.  
  225.  
  226. Heinanen & Govindan                                             [Page 4]
  227.  
  228. RFC 1735                    NBMA ARP (NARP)                December 1994
  229.  
  230.  
  231.    Source and Destination IP Addresses
  232.      Respectively, these are the IP addresses of the NARP requestor and
  233.      the target terminal for which the NBMA address is desired.
  234.  
  235.    NBMA Length and NBMA Address
  236.      The NBMA length field is the length of the NBMA address of the
  237.      source terminal in bits.  The NBMA address itself is zero-filled to
  238.      the nearest 32-bit boundary.
  239.  
  240.    NARP Reply
  241.  
  242.        0                   1                   2                   3
  243.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  244.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  245.       |    Version    |   Hop Count   |          Checksum             |
  246.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  247.       |     Type      |      Code     |           Unused              |
  248.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  249.       |                    Destination IP address                     |
  250.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  251.       |                      Source IP address                        |
  252.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  253.       | NBMA length   |                NBMA address                   |
  254.       +-+-+-+-+-+-+-+-+                                               |
  255.       |                  (variable length)                            |
  256.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  257.  
  258.    Version
  259.      The NARP version number.  Currently this value is 1.
  260.  
  261.    Hop Count
  262.      The Hop count indicates the maximum number of NASs that a request
  263.      or reply is allowed to traverse before being discarded.
  264.  
  265.    Checksum
  266.      The standard IP checksum over the entire NARP packet (starting with
  267.      the fixed header).
  268.  
  269.    Type
  270.      The NARP packet type.  The NARP Reply has a Type code 2.
  271.  
  272.    Code
  273.      NARP replies may be positive or negative.  A Positive, Non-
  274.      authoritative Reply carries a code of 1, while a Positive,
  275.      Authoritative Reply carries a code of 2. A Negative, Non-
  276.      authoritative Reply carries a code of 3 and a Negative,
  277.      Authoritative reply carries a code of 4.
  278.  
  279.  
  280.  
  281.  
  282. Heinanen & Govindan                                             [Page 5]
  283.  
  284. RFC 1735                    NBMA ARP (NARP)                December 1994
  285.  
  286.  
  287.      The general rule is that a NAS should not reply to an NARP request
  288.      for authoritative information with cached information, but may do
  289.      so for an NARP request.  A NAS implementation is allowed to relax
  290.      this rule and return non-authoritative information even in case
  291.      authorative was desired if the NAS becomes heavily loaded and the
  292.      cached information is very recently updated.
  293.  
  294.    Source and Destination IP Address
  295.      Respectively, these are the IP addresses of the NARP requestor and
  296.      the target terminal for which the NBMA address is desired.
  297.  
  298.    NBMA Length and NBMA Address
  299.      The NBMA length field is the length of the NBMA address of the
  300.      destination terminal in bits.  The NBMA address itself is zero-
  301.      filled to the nearest 32-bit boundary.  Negative replies do not
  302.      carry the NBMA length or the NBMA address field.
  303.  
  304.      A NAS may cache NBMA replies.
  305.  
  306. 5. Protocol Operation
  307.  
  308.    The external behavior of a NAS may be described in terms of two
  309.    procedures (processRequest and processReply) operating on two tables
  310.    (forwardingTable and cacheTable).  In an actual implementation, the
  311.    code and data structures may be realized differently.
  312.  
  313.    Each NAS has a forwardingTable consisting of entries with the fields:
  314.  
  315.        <networkLayerAddrPrefix, type, outIf, outIfAddr>
  316.  
  317.    The networkLayerAddrPrefix field identifies a set of IP addresses
  318.    known to the NAS.  It consists of two subfields <ipAddr, mask>.
  319.  
  320.    The type field indicates the type of the networkLayerAddrPrefix.  The
  321.    possible values are:
  322.  
  323.    - locallyServed: The NAS is itself serving the
  324.      networkLayerAddrPrefix.  The outIf field denotes the NBMA interface
  325.      via which the served terminals can be reached and the outIfAddr
  326.      field has no meaning.  Such a forwardingTable entry has been
  327.      created by manual configuration.
  328.  
  329.    - nasLearned: The NAS has learned about the networkLayerAddrPrefix
  330.      from another NAS.  The outIf and outIfAddr fields, respectively,
  331.      denote the NBMA interface and IP address of this next hop NAS.
  332.      Such a forwardingTable entry is a result of network layer address
  333.      prefix information exchange with one of the NAS' peer NASs.
  334.  
  335.  
  336.  
  337.  
  338. Heinanen & Govindan                                             [Page 6]
  339.  
  340. RFC 1735                    NBMA ARP (NARP)                December 1994
  341.  
  342.  
  343.    - externallyLearned: The NAS has learned about the
  344.      networkLayerAddrPrefix from a peer router outside the served NBMA.
  345.      The outIf and outIfAddr fields, respectively, denote the NBMA
  346.      interface and IP address of this next hop NAS.  Such a
  347.      forwardingTable entry is a result of network layer address prefix
  348.      information exchange with one of the NAS' peer routers.
  349.  
  350.    The protocol used to exchange networkLayerAddrPrefix information
  351.    among the NASs can be any regular IP intra-domain or inter-domain
  352.    routing protocol.
  353.  
  354.    In addition to the forwardingTable, each NAS has an NARP cacheTable
  355.    consisting of entries with the fields:
  356.  
  357.        <networkLayerAddr, nbmaAddr, timeStamp>
  358.  
  359.    The entries in the cacheTable are learned from NARP replies
  360.    traversing the NAS.  In case of a negative cache entry the nbmaAddr
  361.    is empty.  The timeStamp field records the time when the cacheTable
  362.    entry has been created or updated.  It is used to determine if an
  363.    entry is a very recent one and to age old entries after a certain
  364.    hold period.
  365.  
  366.    The following pseudocode defines how NBMA NARP requests and replies
  367.    are processed by an NAS.
  368.  
  369.   procedure processRequest(request);
  370.     let bestMatch == matchForwardingTable(request.dIPa) do
  371.        if bestMatch then
  372.           if bestMatch.type == locallyServed then
  373.              let nbmaAddr == arp(request.dIPa) do
  374.                 if nbmaAddr then
  375.                    genPosAuthReply(request.sIPa, request.dIPa, nbmaAddr)
  376.                 else
  377.                    genNegAuthReply(request.sIPa, request.dIPa)
  378.                 end
  379.              end
  380.           elseif bestMatch.type == nasLearned then
  381.              if not requestForAuthInfo?(request) or
  382.                    realBusyRightNow?() then
  383.                 let cacheMatch == matchCacheTable(request.dIPa) do
  384.                    if cacheMatch and
  385.                          (not requestForAuthInfo?(request) or
  386.                             realRecentCacheEntry?(cacheMatch)) then
  387.                       if cacheMatch.nbmaAddr == EMPTY then
  388.                          genNegNonAuthReply(request.sIPa, request.dIPa)
  389.                       else
  390.                          genPosNonAuthReply(request.sIPa, request.dIPa,
  391.  
  392.  
  393.  
  394. Heinanen & Govindan                                             [Page 7]
  395.  
  396. RFC 1735                    NBMA ARP (NARP)                December 1994
  397.  
  398.  
  399.                             cacheMatch.nbmaAddr)
  400.                       end
  401.                    else /* no cache match */
  402.                       forwardRequest(request, bestMatch.OutIf,
  403.                          bestMatch.OutIfAddr)
  404.                    end
  405.                 end
  406.              else /* request for authoritative information */
  407.                 forwardRequest(request, bestMatch.OutIf,
  408.                    bestMatch.OutIfAddr)
  409.              end
  410.           else /* bestMatch.type == externallyLearned */
  411.              genNegAuthReply(request.sIPa, request.dIPa)
  412.           end
  413.        else /* no match in forwardingTable */
  414.           genNegAuthReply(request.sIPa, request.dIPa)
  415.        end
  416.     end
  417.   end
  418.  
  419.   procedure processReply(reply);
  420.     addCacheTableEntry(reply.dIPa, reply.nbmaAddr, currentTime);
  421.     if reply.sIPa == selfIpAddr then
  422.        /* reply is to the NAS itself */
  423.     else
  424.        let bestMatch == matchForwardingTable(reply.sIPa) do
  425.           if bestMatch then
  426.              forwardReply(reply, bestMatch.outIf, bestMatch.outIfAddr)
  427.           end
  428.        end
  429.     end
  430.   end
  431.  
  432.    The semantics of the procedures used in the pseudocode are explained
  433.    below.
  434.  
  435.    matchForwardingTable(ipAddress) returns the forwardingTable entry
  436.    whose networkLayerAddrPrefix field is the longest match for ipAddress
  437.    or FALSE if no match is found.
  438.  
  439.    arp(ipAddress) resolves the NBMA address corresponding to ipAddress.
  440.    It returns FALSE if the resolution fails.
  441.  
  442.    genPosAuthReply(sourceIpAddr, destIpAddr, destNbmaAddr) and
  443.    genPosNonAuthReply(sourceIpAddr, destIpAddr, destNbmaAddr) generate a
  444.    positive, authoritative and non-authoritative reply with
  445.    sourceIpAddr, destIpAddr, and destNbmaAddr in Source IP address,
  446.    Destination IP address, and NBMA Address fields, respectively.
  447.  
  448.  
  449.  
  450. Heinanen & Govindan                                             [Page 8]
  451.  
  452. RFC 1735                    NBMA ARP (NARP)                December 1994
  453.  
  454.  
  455.    genNegAuthReply(sourceIpAddr, destIpAddr) and
  456.    genNegNonAuthReply(sourceIpAddr, destIpAddr) respectively generate a
  457.    negative, authoritative and non-authoritative reply with sourceIpAddr
  458.    and destIpAddr in Source IP address and Destination IP address
  459.    fields, respectively.
  460.  
  461.    requestForAuthInfo?(request) tests if request is a Request for
  462.    authoritative information.
  463.  
  464.    realBusyRightNow?() returns TRUE if the NAS is heavily loaded and
  465.    FALSE otherwise.
  466.  
  467.    realRecentCacheEntry?(cacheTableEntry) returns TRUE if the
  468.    cacheTableEntry is very recently updated and FALSE otherwise.
  469.  
  470.    matchCacheTable(ipAddr) returns a cacheTable entry whose
  471.    networkLayerAddr field is equal to ipAddr or FALSE if no match is
  472.    found.
  473.  
  474.    forwardRequest(request, interface, ipAddr) decrements the Hop count
  475.    field of request, recomputes the NARP Checksum field, and forwards
  476.    request to ipAddr of interface provided that the value of the Hop
  477.    count field remains positive.
  478.  
  479.    addCacheTableEntry(ipAddr, nbmaAddr, time) adds a new entry to the
  480.    cacheTable or overwrites an existing entry whose networkLayerAddr
  481.    field is equal to ipAddr.
  482.  
  483.    forwardReply(reply, interface, ipAddr) decrements the Hop count field
  484.    of request, recomputes the NARP Checksum field, and forwards reply to
  485.    ipAddr of interface provided that the value of the Hop count field
  486.    remains positive.
  487.  
  488.    Like NASs, each NBMA terminal has a forwardingTable and a cacheTable.
  489.    The forwardingTable is either manually configured or filled via
  490.    reachability information exchange with the terminal's NASs or peer
  491.    routers.
  492.  
  493.    When the terminal wishes to find out the NBMA address of a particular
  494.    destination terminal, it first checks if a matching entry is found in
  495.    the forwardingTable.  If not, the destination is unreachable and the
  496.    terminal gives up.  If a forwardingTable entry is found, and if the
  497.    next hop belongs to one of the terminal's NASs, the terminal next
  498.    consults its cacheTable to obtain the NBMA address.  If no cache
  499.    match is found, the terminal generates a NARP request to the next hop
  500.    NAS.  If the reply to the NARP request is positive, the terminal
  501.    learns the NBMA address and updates its cacheTable with the new
  502.    information.
  503.  
  504.  
  505.  
  506. Heinanen & Govindan                                             [Page 9]
  507.  
  508. RFC 1735                    NBMA ARP (NARP)                December 1994
  509.  
  510.  
  511. 6. Discussion
  512.  
  513.    The NARP semantics resembles closely the ATMARP semantics described
  514.    in [2].  The only actual differences are:
  515.  
  516.    - NARP requests and replies include a hop count to prevent them from
  517.      looping forever in case of misconfigured NAS routing.
  518.  
  519.    - NARP request and replies distinguish between authoritative and
  520.      non-authoritative information.
  521.  
  522.    In order to keep the NBMA terminals as simple as possible, it would
  523.    be desirable to extend the the ATMARP protocol a little further so
  524.    that it could be also used as the terminal-NAS protocol.  This could
  525.    be easily accomplished just by adding three new operation codes to
  526.    ATMARP to cover the different kinds of queries and responses.  NARP
  527.    would then become the NAS-NAS protocol.  Finally, if the NASs are
  528.    co-located with the "classical" ATM ARP servers, the terminals would
  529.    not need to make any distinction between between local and foreign IP
  530.    subnetworks.
  531.  
  532.    The NASs can also act as "connectionless servers" for the terminal by
  533.    advertizing to it all destinations no matter if they are inside or
  534.    outside the served NBMA.  Then, the terminal could choose either to
  535.    try to resolve the NBMA address of the destination or just to send
  536.    the IP packets to the NAS.  The latter option may be desirable if
  537.    communication with the destination is short-lived and/or doesn't
  538.    require much network resources.
  539.  
  540.    NARP supports portability of NBMA terminals.  A terminal can be moved
  541.    anywhere within the NBMA network and still keep its original IP
  542.    address as long as its NAS(s) remain the same.  Requests for
  543.    authoritative information will always return the correct NBMA
  544.    address.
  545.  
  546. References
  547.  
  548.    [1] Plummer, D., "An Ethernet Address Resolution Protocol - or -
  549.        Converting Network Protocol Addresses to 48.bit Ethernet Address
  550.        for Transmission on Ethernet Hardware", STD 37, RFC 826, MIT,
  551.        November 1982.
  552.  
  553.    [2] Laubach, M., "Classical IP and ARP over ATM", RFC 1577, Hewlett-
  554.        Packard Laboratories, January 1994.
  555.  
  556.    [3] Piscitello, D., and J. Lawrence, "Transmission of IP Datagrams
  557.        over the SMDS Service, RFC 1209, Bell Communications Research,
  558.        March 1991.
  559.  
  560.  
  561.  
  562. Heinanen & Govindan                                            [Page 10]
  563.  
  564. RFC 1735                    NBMA ARP (NARP)                December 1994
  565.  
  566.  
  567. Acknowledgements
  568.  
  569.    We would like to thank John Burnett of Adaptive, Dennis Ferguson of
  570.    ANS, Joel Halpern of Network Systems, and Paul Francis of Bellcore
  571.    for their valuable insight and comments to earlier versions of this
  572.    draft.
  573.  
  574. Security Considerations
  575.  
  576.    Security issues are not discussed in this memo.
  577.  
  578. Authors' Addresses
  579.  
  580.    Juha Heinanen
  581.    Telecom Finland
  582.    PO Box 228
  583.    SF-33101 Tampere
  584.    Finland
  585.  
  586.    Phone: +358 49 500 958
  587.    EMail: Juha.Heinanen@datanet.tele.fi
  588.  
  589.  
  590.    Ramesh Govindan
  591.    USC/Information Sciences Institute
  592.    4676 Admiralty Way
  593.    Marina del Rey, CA 90292
  594.  
  595.    Phone: +1 310-822-1511
  596.    EMail: govindan@isi.edu
  597.  
  598.  
  599.  
  600.  
  601.  
  602.  
  603.  
  604.  
  605.  
  606.  
  607.  
  608.  
  609.  
  610.  
  611.  
  612.  
  613.  
  614.  
  615.  
  616.  
  617.  
  618. Heinanen & Govindan                                            [Page 11]
  619.  
  620.