Inverse Address Resolution Protocol
obsoleted by
- rfc-2390 — Inverse Address Resolution Protocol
Extracted elements (15)
InARP does not broadcast requests, unlike ARP, because the hardware address of the destination station is already known. This makes it more efficient than simulating a broadcast with multiple copies of the same message.
InARP was created because Frame Relay stations learn of new virtual circuits via signalling but receive no protocol address for the remote side, leaving the circuit unusable without a discovery mechanism. RARP was rejected because it returns the protocol address of the requesting station, not the remote station, and IP-specific mechanisms were too limiting for a multi-protocol solution.
Hardware and protocol type values for InARP are drawn from the same Assigned Numbers registry as ARP. For IP over Frame Relay, hardware address length is 2–4 bytes and protocol address length is 4 bytes.
Procedures for using InARP over a Frame Relay network are identical to those for ARP and RARP discussed in RFC-1294 (Multiprotocol Interconnect over Frame Relay Networks).
Q.922 addresses in InARP packets over Frame Relay must have the C/R, FECN, BECN, and DE bits set to zero.
A multi-addressed host receiving an InARP request MUST choose one address with which to respond. It must examine the protocol address of the requesting station and respond with a protocol address corresponding to the same network (e.g., same IP subnet) as the requester.
A requesting station MUST format an InARP request by inserting its source hardware and protocol addresses, the known target hardware address, and zero-filling the target protocol address field. The packet is then sent directly to the target station without broadcasting.
If a multi-addressed station does not have an address appropriate for the request (e.g., no IP address on the requested subnet), it SHOULD NOT respond to the InARP request.
If a station is unable or unwilling to reply to an InARP request, it ignores the request. When the requesting station receives an InARP reply, it MAY complete the ARP table entry and use the provided address information.
Upon receiving an InARP request, a station MAY place the requester's protocol address/hardware address mapping into its ARP cache. The receiving station MAY assume any InARP request it receives is destined for it and MAY reply using the request's source addresses as the reply's target addresses.
For an InARP reply over Frame Relay: ar$hrd = 0x000F, ar$op = 9, ar$sha = Q.922 address of responding station, ar$spa = the requested protocol address, ar$tha = Q.922 address of requesting station, ar$tpa = protocol address of requesting station.
For an InARP request over Frame Relay: ar$hrd = 0x000F (Frame Relay hardware type), ar$op = 8, ar$sha = Q.922 address of requesting station, ar$spa = protocol address of requesting station, ar$tha = Q.922 address of the newly announced virtual circuit, ar$tpa = 0 (the unknown address being sought).
Two new ARP operation codes are defined: InARP request = 8, InARP reply = 9. These values were chosen to avoid conflicts with other ARP extensions.
Security issues are not addressed in this memo. No authentication or integrity protection is specified for InARP messages.
InARP uses the identical packet format as ARP: ar$hrd (16 bits, hardware type), ar$pro (16 bits, protocol type), ar$hln (8 bits, hardware address byte length n), ar$pln (8 bits, protocol address byte length m), ar$op (16 bits, operation code), ar$sha (n bytes, source hardware address), ar$spa (m bytes, source protocol address), ar$tha (n bytes, target hardware address), ar$tpa (m bytes, target protocol address).