As per Relevance of the word requesting, we have this rfc below:
Network Working Group T.
Request for Comments: 1293 C.
Wellfleet Communications, Inc
January 1992
Inverse Address Resolution
1. Status of this
This RFC specifies an IAB standards track protocol for the
community, and requests discussion and suggestions for improvements
Please refer to the current edition of the "IAB Official
Standards" for the standardization state and status of this protocol
Distribution of this memo is unlimited
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
3.
The following language conventions are used in the items
specification in this document
o Must, Will, Shall or Mandatory -- the item is an
requirement of the specification
o Should or Recommended -- the item should generally
followed for all but exceptional circumstances
o May or Optional -- the item is truly optional and may
followed or ignored according to the needs of
implementor
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
Bradley, Brown [Page 1]
RFC 1293 Inverse ARP January 1992
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 are
Frame Relay equivalent to a hardware address. Periodically,
the exchange of signalling messages, a network may announce a
virtual circuit with its corresponding DLCI. Unfortunately,
addressing is not included in the announcement. The
receiving such an indication will learn of the new connection,
will not be able to address the other side. Without a
configuration or mechanism for discovering the protocol address
the other side, this new virtual circuit is 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 as
wanted. IP specific mechanisms were limiting since we wished
allow protocol address resolution of many protocols. For
reason, we expanded the ARP protocol
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 efficiently than simulating
broadcast with multiple copies of the same message and it is
flexible than relying on static configuration
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
Bradley, Brown [Page 2]
RFC 1293 Inverse ARP January 1992
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 between 2 and 4,
the protocol address length is 4.
The operation code indicates the type of message, request or reply
InARP request = 8
InARP reply = 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. A
station simply formats a request by inserting its source hardware
protocol addresses and the known target hardware address. It
zero fills the target protocol address field. Finally, it
encapsulate the packet for the specific network and send it
to the target station
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 station
format a proper reply using the source addresses from the request
the target addresses of the reply. If the station is unable
unwilling to reply, it ignores the request
When the requesting station receives the InARP reply, it may
the ARP table entry and use the provided address information. Note
as with ARP, information learned via InARP may be aged or
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
Bradley, Brown [Page 3]
RFC 1293 Inverse ARP January 1992
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 may choose to send an InARP request for
of the addresses defined for the given interface. It should
noted, however, that the receiving side may answer some or none
the requests depending on its configuration
7.2. Protocol Operation Within Frame
One case where Inverse ARP can be used is when a new virtual
is signalled. The Frame Relay station may format an InARP
addressed to the new virtual circuit. If the other side
InARP, it may return a reply indicating the protocol
requested
The format for an InARP request is a follows
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 address of requesting
ar$spa - protocol address of requesting
ar$tha - Q.922 addressed of newly announced virtual
ar$tpa - 0; This is what we're looking
Bradley, Brown [Page 4]
RFC 1293 Inverse ARP January 1992
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
Procedures for using InARP over a Frame Relay network are
to those for using ARP and RARP discussed in section 10 of
Multiprotocol Interconnect over Frame Relay Networks document [3].
8.
[1] Plummer, David C., "An Ethernet Address Resolution Protocol",
RFC-826, November 1982.
[2] Reynolds, J. and Postel, J., "Assigned Numbers", RFC-1060, ISI
March 1990.
[3] Bradley, T., Brown, C., Malis, A., "Multiprotocol
over Frame Relay Networks", RFC-1294, January 1992.
[4] Finlayson, Mann, Mogul, Theimer, "A Reverse Address
Protocol", RFC-903, Stanford University, June 1984.
9. Security
Security issues are not addressed in this memo
Bradley, Brown [Page 5]
RFC 1293 Inverse ARP January 1992
10. Authors'
Terry
Wellfleet Communications, Inc
15 Crosby
Bedford, MA 01730
Phone: (617) 275-2400
Email: tbradley@wellfleet.
Caralyn
Wellfleet Communications, Inc
15 Crosby
Bedford, MA 01730
Phone: (617) 275-2400
Email: cbrown@wellfleet.
Bradley, Brown [Page 6]
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
