rfc2390.txt

RFC 的详细文档！


RFC 2390          Inverse Address Resolution Protocol     September 1998


   Procedures for using InARP over a Frame Relay network are as follows:

   Because DLCIs within most Frame Relay networks have only local
   significance, an end station will not have a specific DLCI assigned
   to itself.  Therefore, such a station does not have an address to put
   into the InARP request or response.  Fortunately, the Frame Relay
   network does provide a method for obtaining the correct DLCIs. The
   solution proposed for the locally addressed Frame Relay network below
   will work equally well for a network where DLCIs have global
   significance.

   The DLCI carried within the Frame Relay header is modified as it
   traverses the network.  When the packet arrives at its destination,
   the DLCI has been set to the value that, from the standpoint of the
   receiving station, corresponds to the sending station.  For example,
   in figure 1 below, if station A were to send a message to station B,
   it would place DLCI 50 in the Frame Relay header.  When station B
   received this message, however, the DLCI would have been modified by
   the network and would appear to B as DLCI 70.

                           ~~~~~~~~~~~~~~~
                          (                )
        +-----+          (                  )             +-----+
        |     |-50------(--------------------)---------70-|     |
        |  A  |        (                      )           |  B  |
        |     |-60-----(---------+            )           |     |
        +-----+         (        |           )            +-----+
                         (       |          )
                          (      |         )  <---Frame Relay
                           ~~~~~~~~~~~~~~~~         network
                                 80
                                 |
                              +-----+
                              |     |
                              |  C  |
                              |     |
                              +-----+

                              Figure 1

      Lines between stations represent data link connections (DLCs).
      The numbers indicate the local DLCI associated with each
      connection.








Bradley, et. al.            Standards Track                     [Page 6]

RFC 2390          Inverse Address Resolution Protocol     September 1998


              DLCI to Q.922 Address Table for Figure 1

              DLCI (decimal)  Q.922 address (hex)
                   50              0x0C21
                   60              0x0CC1
                   70              0x1061
                   80              0x1401

      For authoritative description of the correlation between DLCI and
      Q.922 [6] addresses, the reader should consult that specification.
      A summary of the correlation is included here for convenience. The
      translation between DLCI and Q.922 address is based on a two byte
      address length using the Q.922 encoding format.  The format is:

                8   7   6   5   4   3    2   1
              +------------------------+---+--+
              |  DLCI (high order)     |C/R|EA|
              +--------------+----+----+---+--+
              | DLCI (lower) |FECN|BECN|DE |EA|
              +--------------+----+----+---+--+

      For InARP, the FECN, BECN, C/R and DE bits are assumed to be 0.

   When an InARP message reaches a destination, all hardware addresses
   will be invalid.  The address found in the frame header will,
   however, be correct. Though it does violate the purity of layering,
   Frame Relay may use the address in the header as the sender hardware
   address.  It should also be noted that the target hardware address,
   in both the InARP request and response, will also be invalid.  This
   should not cause problems since InARP does not rely on these fields
   and in fact, an implementation may zero fill or ignore the target
   hardware address field entirely.

   Using figure 1 as an example, station A may use Inverse ARP to
   discover the protocol address of the station associated with its DLCI
   50.  The Inverse ARP request would be as follows:

              InARP Request from A (DLCI 50)
              ar$op   8       (InARP request)
              ar$sha  unknown
              ar$spa  pA
              ar$tha  0x0C21  (DLCI 50)
              ar$tpa  unknown

   When Station B receives this packet, it will modify the source
   hardware address with the Q.922 address from the Frame Relay header.
   This way, the InARP request from A will become:




Bradley, et. al.            Standards Track                     [Page 7]

RFC 2390          Inverse Address Resolution Protocol     September 1998


              ar$op   8       (InARP request)
              ar$sha  0x1061  (DLCI 70)
              ar$spa  pA
              ar$tha  0x0C21  (DLCI 50)
              ar$tpa  unknown.

   Station B will format an Inverse ARP response and send it to station
   A:

              ar$op   9       (InARP response)
              ar$sha  unknown
              ar$spa  pB
              ar$tha  0x1061  (DLCI 70)
              ar$tpa  pA

   The source hardware address is unknown and when the response is
   received, station A will extract the address from the Frame Relay
   header and place it in the source hardware address field.  Therefore,
   the response will become:

              ar$op   9       (InARP response)
              ar$sha  0x0C21  (DLCI 50)
              ar$spa  pB
              ar$tha  0x1061  (DLCI 70)
              ar$tpa  pA

   This means that the Frame Relay interface must only intervene in the
   processing of incoming packets.

   Also, see [3] for a description of similar procedures for using ARP
   [1] and RARP [4] with Frame Relay.

8.  Security Considerations

   This document specifies a functional enhancement to the ARP family of
   protocols, and is subject to the same security constraints that
   affect ARP and similar address resolution protocols.  Because
   authentication is not a part of ARP, there are known security issues
   relating to its use (e.g., host impersonation).  No additional
   security mechanisms have been added to the ARP family of protocols by
   this document.










Bradley, et. al.            Standards Track                     [Page 8]

RFC 2390          Inverse Address Resolution Protocol     September 1998


9.  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, November
       1982.

   [2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
       October 1994.  See also: http://www.iana.org/numbers.html

   [3] Bradley, T., Brown, C., and A. Malis, "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, June 1984.

   [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
       Levels", BCP 14, RFC 2119, March 1997.

   [6] Information technology - Telecommunications and Information
       Exchange between systems - Protocol Identification in the Network
       Layer, ISO/IEC TR 9577: 1992.

10.  Authors' Addresses

   Terry Bradley
   Avici Systems, Inc.
   12 Elizabeth Drive
   Chelmsford, MA  01824

   Phone: [phone]
   EMail: [e-mail]


   Caralyn Brown
   Consultant

   EMail:  [e-mail]


   Andrew Malis
   Ascend Communications, Inc.
   1 Robbins Road
   Westford, MA  01886

   Phone:  [phone]
   EMail:  [e-mail]




Bradley, et. al.            Standards Track                     [Page 9]

RFC 2390          Inverse Address Resolution Protocol     September 1998


11.  Full Copyright Statement

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
























Bradley, et. al.            Standards Track                    [Page 10]