summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2390.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc2390.txt')
-rw-r--r--doc/rfc/rfc2390.txt563
1 files changed, 563 insertions, 0 deletions
diff --git a/doc/rfc/rfc2390.txt b/doc/rfc/rfc2390.txt
new file mode 100644
index 0000000..122c181
--- /dev/null
+++ b/doc/rfc/rfc2390.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Network Working Group T. Bradley
+Request for Comments: 2390 Avici Systems, Inc.
+Obsoletes: 1293 C. Brown
+Category: Standards Track Consultant
+ A. Malis
+ Ascend Communications, Inc.
+ September 1998
+
+
+ Inverse Address Resolution Protocol
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (1998). All Rights Reserved.
+
+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.
+
+ This memo replaces RFC 1293. The changes from RFC 1293 are minor
+ changes to formalize the language, the additions of a packet diagram
+ and an example in section 7.2, and a new security section.
+
+3. Conventions
+
+ The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
+ SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
+ document, are to be interpreted as described in [5].
+
+
+
+
+
+
+
+
+Bradley, et. al. Standards Track [Page 1]
+
+RFC 2390 Inverse Address Resolution Protocol September 1998
+
+
+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.
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+Bradley, et. al. Standards Track [Page 2]
+
+RFC 2390 Inverse Address Resolution Protocol September 1998
+
+
+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
+ response.
+
+ InARP request = 8
+ InARP response = 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
+ the target protocol address field. Finally, it will encapsulate the
+ packet for the specific network and send it directly to the target
+ station.
+
+
+
+
+
+Bradley, et. al. Standards Track [Page 3]
+
+RFC 2390 Inverse Address Resolution Protocol September 1998
+
+
+ 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 response using the source addresses from the
+ request as the target addresses of the response. If the station is
+ unable or unwilling to reply, it ignores the request.
+
+ When the requesting station receives the InARP response, 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 response
+ indicating the protocol address requested.
+
+ 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:
+
+
+
+Bradley, et. al. Standards Track [Page 4]
+
+RFC 2390 Inverse Address Resolution Protocol September 1998
+
+
+ +----------+----------+
+ | 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 [6] address of requesting station
+ ar$spa - protocol address of requesting station
+ ar$tha - Q.922 address 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
+ DE bits set to zero.
+
+
+
+
+
+
+Bradley, et. al. Standards Track [Page 5]
+
+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: (978) 250-3344
+ EMail: tbradley@avici.com
+
+
+ Caralyn Brown
+ Consultant
+
+ EMail: cbrown@juno.com
+
+
+ Andrew Malis
+ Ascend Communications, Inc.
+ 1 Robbins Road
+ Westford, MA 01886
+
+ Phone: (978) 952-7414
+ EMail: malis@ascend.com
+
+
+
+
+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]
+