Inverse Address Resolution Protocol
obsoletes
- rfc-1293 — Inverse Address Resolution Protocol
Extracted elements (20)
Because DLCIs within most Frame Relay networks have only local significance, a station does not have a specific DLCI assigned to itself. The Frame Relay network modifies the DLCI in the frame header as the packet traverses the network, so the receiving station uses the header DLCI as the sender's hardware address.
InARP operation codes 8 and 9 were chosen specifically to avoid conflicting with other ARP extensions already assigned in the ARP opcode space.
IP-specific resolution mechanisms were rejected because they would not allow resolution of protocols other than IP. InARP was built as an extension to ARP to remain protocol-agnostic and support multiple network-layer protocols.
Reverse ARP (RARP) was considered but rejected because RARP responses return the protocol address of the requesting station, not the station receiving the request. InARP was designed to resolve the protocol address of a remote station associated with a known hardware address (DLCI).
Hardware and protocol type values for InARP are the same as those for ARP and are found in the Assigned Numbers RFC. This ensures InARP is compatible with the existing ARP type space.
The target hardware address in both InARP request and response over Frame Relay will be invalid. This should not cause problems since InARP does not rely on these fields; an implementation may zero-fill or ignore the target hardware address field entirely.
When an InARP message reaches its destination over Frame Relay, all hardware addresses in the packet will be invalid; the correct address is found in the Frame Relay frame header. The receiving station should use the address from the frame header as the sender hardware address, even though this violates layering purity.
A multi-addressed host receiving an InARP request must choose one address with which to respond, selecting the protocol address corresponding to the same network/subnet as the requesting station. If no appropriate address exists for the request, it should not respond.
A multi-addressed host should send an InARP request for each of the addresses defined for the given interface.
For every InARP request received, 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.
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.
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.
InARP does not broadcast requests, unlike ARP. Because the hardware address of the destination station is already known, requests are sent directly to the target station.
InARP uses the same packet format as standard ARP, with fields ar$hrd (16 bits, hardware type), ar$pro (16 bits, protocol type), ar$hln (8 bits, hardware address length), ar$pln (8 bits, protocol address length), ar$op (16 bits, operation code), ar$sha, ar$spa, ar$tha, and ar$tpa.
The requesting station formats an InARP request by inserting its source hardware and protocol addresses and the known target hardware address, then zero-fills the target protocol address field, which is the unknown value being resolved.
InARP is subject to the same security constraints as ARP and similar address resolution protocols. Because authentication is not part of ARP, there are known security issues such as host impersonation. No additional security mechanisms have been added by this document.
For IP over Frame Relay, ar$hrd is set to 0x000F (Frame Relay), ar$hln is 2, 3, or 4 bytes (Q.922 address length), ar$pln is 4 bytes for IP, ar$op is 8 (request) or 9 (response), and ar$tpa is zero-filled in the request since it is the unknown value being requested.
InARP operation codes are 8 for InARP request and 9 for InARP response. These values were chosen to avoid conflict with other ARP extensions.
InARP packets over Frame Relay are encapsulated using NLPID/SNAP format per RFC 1490, with Q.922 address header, control 0x03, pad 0x00, NLPID 0x80, OUI 0x00 0x00 0x00, and PID 0x08 0x06 indicating the ARP protocol.
Q.922 addresses encode DLCIs in a two-byte format: high-order DLCI bits plus C/R and EA in the first byte, lower DLCI bits plus FECN, BECN, DE, and EA in the second byte. For InARP, FECN, BECN, C/R, and DE bits are assumed to be zero.