This article was accepted into the corpus but its outbound wikilinks were never NER-processed — typical at the deepest BFS hop or when the run's entity cap was reached. No expansion funnel to show.
| Inverse ARP | |
|---|---|
| Name | Inverse ARP |
| Acronym | InARP |
| Developer | Xerox PARC |
| Introduced | 1980s |
| Status | Obsolete/Legacy |
| Domain | Internet Protocol Suite |
| Layer | Data Link Layer |
Inverse ARP Inverse ARP is a legacy network protocol used to discover protocol addresses associated with a known hardware address on a Local Area Network segment. It was designed to complement Address Resolution Protocol by allowing devices that already know a Data Link Layer address to request an associated Internet Protocol address, aiding early Packet-switched network deployments and Wide Area Network services.
Inverse ARP operates as a companion technique to Address Resolution Protocol within link-layer environments such as IEEE 802.3, Frame Relay, Asynchronous Transfer Mode, and other circuit-switched or packet-switched link technologies. The protocol was specified to support environments where endpoints possess a received hardware address (for example, a DLCI or MAC address) but require the corresponding IP address or other protocol address to establish higher-layer communications. It was particularly useful for preconfigured Virtual Circuit infrastructures employed by telecommunication carriers and commercial enterprise networking solutions.
Inverse ARP uses a request–reply model initiated by a node that knows the link-layer address of a peer but lacks the peer’s protocol-layer address. The initiator sends an InARP request frame containing the sender’s protocol-layer address fields and the target hardware address; the target responds with an InARP reply providing its protocol-layer address. This exchange is synchronous with link-layer framing used in X.25 and Frame Relay links and mirrors the operational symmetry of Address Resolution Protocol while reversing the direction of address discovery.
The InARP packet format parallels the structure of ARP packets with fields for hardware type, protocol type, hardware length, protocol length, operation code, sender hardware address, sender protocol address, target hardware address, and target protocol address. Common operation codes include request and reply; extended uses defined in vendor extensions allowed additional opcode semantics for non-IP protocol families such as DECnet and XNS. The format allowed mapping between a hardware identifier like a Data Link Connection Identifier and an Internet Protocol address or alternative protocol namespace.
Inverse ARP was used extensively in early Frame Relay service deployments by telecommunications providers and in PPP-adjacent scenarios where dynamic discovery reduced manual configuration burden for network administrators. Service provider access devices and customer premises equipment benefited when establishing Virtual Private Network overlays and when integrating legacy mainframe systems with emerging TCP/IP infrastructures. Vendors in the networking space incorporated InARP into routers, switches, and access concentrators to automate provisioning across leased-line and switched virtual circuit topologies.
Inverse ARP lacks cryptographic authentication and originates from an era before widespread threat models that include spoofing, replay, and man-in-the-middle attacks associated with modern threats like those targeted at Border Gateway Protocol and Dynamic Host Configuration Protocol. Because InARP replies could be forged on a shared link, adversaries could inject incorrect IP address mappings leading to traffic interception or denial-of-service against systems such as UNIX System V hosts or embedded router platforms. Network operators migrated to mechanisms with stronger binding guarantees, such as IPsec, IEEE 802.1X, and authenticated control-plane protocols to mitigate these risks.
Inverse ARP emerged alongside contemporaneous developments in internetworking in the 1980s, influenced by work at Xerox PARC, Stanford University, and industry consortia addressing interoperability among WAN access technologies. The protocol was documented in early informational and standards-track documents associated with the Internet Engineering Task Force and was implemented by vendors such as Cisco Systems, Juniper Networks (predecessor companies), and other equipment manufacturers serving the telecom market. As IP address assignment and access mechanisms evolved, InARP’s role diminished in favor of protocols and services standardized by bodies like the IETF and regional registries.
Implementations appeared in router and switch firmware from vendors including Cisco Systems, Bay Networks, and equipment from legacy manufacturers serving carrier infrastructures. Interoperability required consistent handling of hardware type codes and protocol type values defined by standards registries maintained by organizations such as IANA. Vendor-specific extensions sometimes hindered cross-vendor operability, prompting operators to prefer unified methods like DHCP for address assignment where link-layer discovery was insufficient. Today, support may remain in some embedded firmware and virtualized network stacks primarily for backward compatibility with legacy Frame Relay and ATM interconnects.
Category:Network protocols