As per Relevance of the word resolution, we have this rfc below:
Network Working Group T.
Request for Comments: 2390 Avici Systems, Inc
Obsoletes: 1293 C.
Category: Standards Track
A.
Ascend Communications, Inc
September 1998
Inverse Address Resolution
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (1998). All Rights Reserved
2.
This memo describes additions to ARP that will allow a station
request a protocol address corresponding to a given hardware address
Specifically, this applies to Frame Relay stations that may have
Data Link Connection Identifier (DLCI), the Frame Relay equivalent
a hardware address, associated with an established Permanent
Circuit (PVC), but do not know the protocol address of the station
the other side of this connection. It will also apply to
networks with similar circumstances
This memo replaces RFC 1293. The changes from RFC 1293 are
changes to formalize the language, the additions of a packet
and an example in section 7.2, and a new security section
3.
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in
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.
This document will rely heavily on Frame Relay as an example of
the Inverse Address Resolution Protocol (InARP) can be useful. It
not, however, intended that InARP be used exclusively with
Relay. InARP may be used in any network that provides
hardware addresses without indicating corresponding
addresses
5.
The motivation for the development of Inverse ARP is a result of
desire to make dynamic address resolution within Frame Relay
possible and efficient. Permanent virtual circuits (PVCs)
eventually switched virtual circuits (SVCs) are identified by a
Link Connection Identifier (DLCI). These DLCIs define a
virtual connection through the wide area network (WAN) and may
thought of as the Frame Relay equivalent to a hardware address
Periodically, through the exchange of signaling messages, a
may announce a new virtual circuit with its corresponding DLCI
Unfortunately, protocol addressing is not included in
announcement. The station receiving such an indication will learn
the new connection, but will not be able to address the other side
Without a new configuration or a mechanism for discovering
protocol address of the other side, this new virtual circuit
unusable
Other resolution methods were considered to solve the problems,
were rejected. Reverse ARP [4], for example, seemed like a
candidate, but the response to a request is the protocol address
the requesting station, not the station receiving the request.
specific mechanisms were limiting since they would not
resolution of other protocols other than IP. For this reason, the
protocol was expanded
Inverse Address Resolution Protocol (InARP) will allow a Frame
station to discover the protocol address of a station associated
the virtual circuit. It is more efficient than sending ARP
on every VC for every address the system wants to resolve and it
more flexible than relying on static configuration
Bradley, et. al. Standards Track [Page 2]
RFC 2390 Inverse Address Resolution Protocol September 1998
6. Packet
Inverse ARP is an extension of the existing ARP. Therefore, it
the same format as standard ARP
ar$hrd 16 bits Hardware
ar$pro 16 bits Protocol
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
ar$sha nbytes source hardware
ar$spa mbytes source protocol
ar$tha nbytes target hardware
ar$tpa mbytes target protocol
Possible values for hardware and protocol types are the same as
for ARP and may be found in the current Assigned Numbers RFC [2].
Length of the hardware and protocol address are dependent on
environment in which InARP is running. For example, if IP is
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
response
InARP request = 8
InARP response = 9
These values were chosen so as not to conflict with other
extensions
7. Protocol
Basic InARP operates essentially the same as ARP with the
that InARP does not broadcast requests. This is because the
address of the destination station is already known
When an interface supporting InARP becomes active, it should
the InARP protocol and format InARP requests for each active PVC
which InARP is active. To do this, a requesting station
formats a request by inserting its source hardware, source
addresses and the known target hardware address. It then zero
the target protocol address field. Finally, it will encapsulate
packet for the specific network and send it directly to the
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'
protocol address/hardware address mapping into its ARP cache as
would any ARP request. Unlike other ARP requests, however,
receiving station may assume that any InARP request it receives
destined for it. For every InARP request, the receiving
should format a proper response using the source addresses from
request as the target addresses of the response. If the station
unable or unwilling to reply, it ignores the request
When the requesting station receives the InARP response, it
complete the ARP table entry and use the provided
information. Note: as with ARP, information learned via InARP may
aged or invalidated under certain circumstances
7.1. Operation with Multi-Addressed
In the context of this discussion, a multi-addressed host will
to a host that has multiple protocol addresses assigned to a
interface. If such a station receives an InARP request, it
choose one address with which to respond. To make such a selection
the receiving station must first look at the protocol address of
requesting station, and then respond with the protocol
corresponding to the network of the requester. For example, if
requesting station is probing for an IP address, the
multi-addressed station should respond with an IP address
corresponds to the same subnet as the requesting station. If
station does not have an address that is appropriate for the
it should not respond. In the IP example, if the receiving
does not have an IP address assigned to the interface that is a
of the requested subnet, the receiving station would not respond
A multi-addressed host should send an InARP request for each of
addresses defined for the given interface. It should be noted
however, that the receiving side may answer some or none of
requests depending on its configuration
7.2. Protocol Operation Within Frame
One case where Inverse ARP can be used is on a frame relay
which supports signaling of DLCIs via a data link
interface. An InARP equipped station connected to such an
will format an InARP request and address it to the new
circuit. If the other side supports InARP, it may return a
indicating the protocol address requested
In a frame relay environment, InARP packets are encapsulated
the NLPID/SNAP format defined in [3] which indicates the
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
ar$pro - protocol type for which you are
(i.e. IP = 0x0800)
ar$hln - 2,3, or 4 byte addressing
ar$pln - byte length of protocol address for which
are searching (for IP = 4)
ar$op - 8; InARP
ar$sha - Q.922 [6] address of requesting
ar$spa - protocol address of requesting
ar$tha - Q.922 address of newly announced virtual
ar$tpa - 0; This is what is being
The InARP response will be completed similarly
ar$hrd - 0x000F the value assigned to Frame
ar$pro - protocol type for which you are
(i.e. IP = 0x0800)
ar$hln - 2,3, or 4 byte addressing
ar$pln - byte length of protocol address for which
are searching (for IP = 4)
ar$op - 9; InARP
ar$sha - Q.922 address of responding
ar$spa - protocol address
ar$tha - Q.922 address of requesting
ar$tpa - protocol address of requesting
Note that the Q.922 addresses specified have the C/R, FECN, BECN,
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
significance, an end station will not have a specific DLCI
to itself. Therefore, such a station does not have an address to
into the InARP request or response. Fortunately, the Frame
network does provide a method for obtaining the correct DLCIs.
solution proposed for the locally addressed Frame Relay network
will work equally well for a network where DLCIs have
significance
The DLCI carried within the Frame Relay header is modified as
traverses the network. When the packet arrives at its destination
the DLCI has been set to the value that, from the standpoint of
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
received this message, however, the DLCI would have been modified
the network and would appear to B as DLCI 70.
~~~~~~~~~~~~~~~
( )
+-----+ ( ) +-----+
| |-50------(--------------------)---------70-| |
| A | ( ) | B |
| |-60-----(---------+ ) | |
+-----+ ( | ) +-----+
( | )
( | ) <---Frame
~~~~~~~~~~~~~~~~
80
|
+-----+
| |
| C |
| |
+-----+
Figure 1
Lines between stations represent data link connections (DLCs).
The numbers indicate the local DLCI associated with
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 0x0CC
70 0x1061
80 0x1401
For authoritative description of the correlation between DLCI
Q.922 [6] addresses, the reader should consult that specification
A summary of the correlation is included here for convenience.
translation between DLCI and Q.922 address is based on a two
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
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
address. It should also be noted that the target hardware address
in both the InARP request and response, will also be invalid.
should not cause problems since InARP does not rely on these
and in fact, an implementation may zero fill or ignore the
hardware address field entirely
Using figure 1 as an example, station A may use Inverse ARP
discover the protocol address of the station associated with its
50. The Inverse ARP request would be as follows
InARP Request from A (DLCI 50)
ar$op 8 (InARP request
ar$sha
ar$spa
ar$tha 0x0C21 (DLCI 50)
ar$tpa
When Station B receives this packet, it will modify the
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
ar$tha 0x0C21 (DLCI 50)
ar$tpa unknown
Station B will format an Inverse ARP response and send it to
A
ar$op 9 (InARP response
ar$sha
ar$spa
ar$tha 0x1061 (DLCI 70)
ar$tpa
The source hardware address is unknown and when the response
received, station A will extract the address from the Frame
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
ar$tha 0x1061 (DLCI 70)
ar$tpa
This means that the Frame Relay interface must only intervene in
processing of incoming packets
Also, see [3] for a description of similar procedures for using
[1] and RARP [4] with Frame Relay
8. Security
This document specifies a functional enhancement to the ARP family
protocols, and is subject to the same security constraints
affect ARP and similar address resolution protocols.
authentication is not a part of ARP, there are known security
relating to its use (e.g., host impersonation). No
security mechanisms have been added to the ARP family of protocols
this document
Bradley, et. al. Standards Track [Page 8]
RFC 2390 Inverse Address Resolution Protocol September 1998
9.
[1] Plummer, D., "An Ethernet Address Resolution Protocol - or -
Converting Network Protocol Addresses to 48.bit Ethernet
for Transmission on Ethernet Hardware", STD 37, RFC 826,
1982.
[2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
October 1994. See also: http://www.iana.org/numbers.
[3] Bradley, T., Brown, C., and A. Malis, "Multiprotocol
over Frame Relay", RFC 1490, July 1993.
[4] Finlayson, R., Mann, R., Mogul, J., and M. Theimer, "A
Address Resolution Protocol", STD 38, RFC 903, June 1984.
[5] Bradner, S., "Key words for use in RFCs to Indicate
Levels", BCP 14, RFC 2119, March 1997.
[6] Information technology - Telecommunications and
Exchange between systems - Protocol Identification in the
Layer, ISO/IEC TR 9577: 1992.
10. Authors'
Terry
Avici Systems, Inc
12 Elizabeth
Chelmsford, MA 01824
Phone: (978) 250-3344
EMail: tbradley@avici.
Caralyn
EMail: cbrown@juno.
Andrew
Ascend Communications, Inc
1 Robbins
Westford, MA 01886
Phone: (978) 952-7414
EMail: malis@ascend.
Bradley, et. al. Standards Track [Page 9]
RFC 2390 Inverse Address Resolution Protocol September 1998
11. Full Copyright
Copyright (C) The Internet Society (1998). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Bradley, et. al. Standards Track [Page 10]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
