RFC 1293

RFC 1293: Inverse Address Resolution Protocol 💖

Okay bestie, this one is Inverse Address Resolution Protocol 🦋 It's from the Network Working Group (Request for Comments: 1293), written by T. Bradley and C. Brown of Wellfleet Communications, Inc., and dated January 1992 ✨ It's an IAB standards track protocol, so it's officially on the standards track 👑 The title block doesn't list anything it obsoletes or updates 🌸

1. Status of this Memo ✨

Okay so this RFC is an IAB standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 💖 For the current standardization state and status, check the current edition of the "IAB Official Protocol Standards" 📚 Distribution of this memo is unlimited 🌈

2. Abstract 🦋

This memo adds stuff to ARP so a station can ask for the protocol address that goes with a given hardware address 🎯 It's aimed at Frame Relay stations. Those have a Data Link Connection Identifier (DLCI), which is the Frame Relay version of a hardware address, tied to an established Permanent Virtual Circuit (PVC). But they don't know the protocol address of the station on the other side 🥺 It also applies to other networks in similar situations 🌸

3. Conventions 💜

Here's how the language in this spec works, so you don't get confused later 🫶

• Must, Will, Shall or Mandatory: the item is an absolute requirement of the specification. No wiggle room 💅
• Should or Recommended: the item should generally be followed, except in exceptional circumstances 🔥
• May or Optional: the item is truly optional, and you can follow it or ignore it depending on what the implementor needs 🧚

4. Introduction 🧚

This document leans heavily on Frame Relay as its main example of how InARP can be useful ✨ But it's not meant to be used only with Frame Relay! InARP MAY be used in any network that gives you destination hardware addresses without the matching protocol addresses 💖

5. Motivation 🌈

The whole reason Inverse ARP exists is to make dynamic address resolution in Frame Relay both possible and efficient 🔥 PVCs (and eventually SVCs) get identified by a DLCI. A DLCI is one virtual connection through the wide area network (WAN), and it's the Frame Relay version of a hardware address 🌸 Every so often, a network can announce a new virtual circuit and its DLCI using signalling messages 📣 BUT the announcement doesn't include protocol addressing 😭 So the station that gets the news learns about the new connection but can't address the other side 💀 Without a new configuration, or some other way to find the protocol address on the other side, that new virtual circuit is unusable 🙈

Other resolution methods were considered and rejected 🤔 Reverse ARP [4] looked like a good candidate, but its response gives you the protocol address of the requesting station, not the station that got the request, which is what we actually wanted. IP-specific mechanisms were limiting too, since we wanted protocol address resolution for many protocols. So we expanded ARP itself ✨

Inverse Address Resolution Protocol (InARP) lets a Frame Relay station discover the protocol address of a station on the other end of a virtual circuit 🦋 It's more efficient than simulating a broadcast with multiple copies of the same message, and more flexible than relying on static configuration 💅

6. Packet Format 🎀

InARP is an extension of regular ARP, so it has the exact same format as standard ARP 🎀

      ar$hrd   16 bits         Hardware type
      ar$pro   16 bits         Protocol type
      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 code
      ar$sha    nbytes         source hardware address
      ar$spa    mbytes         source protocol address
      ar$tha    nbytes         target hardware address
      ar$tpa    mbytes         target protocol address

The possible values for hardware and protocol types are the same as for ARP, and you can find them in the current Assigned Numbers RFC [2] 📚

The lengths of the hardware and protocol addresses depend on the environment InARP is running in 🌸 For example, if IP is running over Frame Relay, the hardware address length is between 2 and 4, and the protocol address length is 4 🍓

The operation code tells you what kind of message it is, a request or a reply:

InARP request  = 8
InARP reply = 9

These values were picked so they don't clash with other ARP extensions ✨

7. Protocol Operation 🚀

Basic InARP works essentially like ARP, with one big difference: InARP does not broadcast requests 🙅 That's because the hardware address of the destination is already known 💖 A requesting station formats its request by filling in its own source hardware and protocol addresses, plus the known target hardware address. Then it zero fills the target protocol address field 🧚 Finally, it encapsulates the packet for the specific network and sends it straight to the target station 🚀

Upon receiving an InARP request, a station MAY put the requester's protocol address/hardware address mapping into its ARP cache, the same way it would with any ARP request. Unlike other ARP requests, though, the receiving station MAY assume that any InARP request it receives is destined for it 🎯 For every InARP request, the receiving station MAY format a proper reply, using the source addresses from the request as the target addresses of the reply. If the station is unable or unwilling to reply, it ignores the request 🙈

When the requesting station receives the InARP reply, it MAY complete the ARP table entry and use the address information provided ✨ Note: just like with ARP, information learned via InARP MAY be aged or invalidated under certain circumstances ⏳

7.1. Operation with Multi-Addressed Hosts 👑

Here, a Multi-Addressed host means a host that has multiple protocol addresses assigned to a single interface 👑 If one of those receives an InARP request, it MUST choose one address to respond with. To make that choice, the receiving station MUST first look at the protocol address of the requesting station, and then respond with the protocol address that matches the requester's network 🎯

For example, if the requesting station is probing for an IP address, the responding multi-addressed station SHOULD respond with an IP address on the same subnet as the requester 🌐 If it doesn't have an address that's appropriate for the request, it SHOULD NOT respond 🙅 In the IP example, if the receiving station doesn't have an IP address on that interface that's part of the requested subnet, it would not respond 💀

A multi-addressed host MAY choose to send an InARP request for each of the addresses defined on the interface. Heads up though: the receiving side MAY answer some or none of those requests, depending on its configuration 🤷

7.2. Protocol Operation Within Frame Relay 🌸

One time InARP is super useful is when a new virtual circuit gets signalled 🦋 The Frame Relay station MAY format an InARP request addressed to the new virtual circuit. If the other side supports InARP, it MAY return a reply with the protocol address that was requested 💜

The format for an InARP request is as follows:

      ar$hrd - 0x000F the value assigned to Frame Relay
      ar$pro - protocol type for which you are searching
                  (i.e.  IP = 0x0800)
      ar$hln - 2,3, or 4 byte addressing length
      ar$pln - byte length of protocol address for which you
                  are searching (for IP = 4)
      ar$op  - 8; InARP request
      ar$sha - Q.922 address of requesting station
      ar$spa - protocol address of requesting station
      ar$tha - Q.922 addressed of newly announced virtual circuit
      ar$tpa - 0; This is what we're looking for

The InARP response gets put together in a similar way:

      ar$hrd - 0x000F the value assigned to Frame Relay
      ar$pro - protocol type for which you are searching
                 (i.e.  IP = 0x0800)
      ar$hln - 2,3, or 4 byte addressing length
      ar$pln - byte length of protocol address for which you
                 are searching (for IP = 4)
      ar$op  - 9; InARP response
      ar$sha - Q.922 address of responding station
      ar$spa - protocol address requested
      ar$tha - Q.922 address of requesting station
      ar$tpa - protocol address of requesting station

Note that the Q.922 addresses specified have the C/R, FECN, BECN, and DE bits set to zero 🌸

Using InARP over a Frame Relay network follows the exact same procedures as ARP and RARP, which are discussed in section 10 of the Multiprotocol Interconnect over Frame Relay Networks document [3] 📖

8. References 📚

• [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 Interconnect over Frame Relay Networks", RFC-1294, January 1992.
• [4] Finlayson, Mann, Mogul, Theimer, "A Reverse Address Resolution Protocol", RFC-903, Stanford University, June 1984.

9. Security Considerations 🙈

Security issues are not addressed in this memo. Read that twice, bestie 😭

10. Authors' Addresses 💌

Terry Bradley
Wellfleet Communications, Inc.
15 Crosby Drive
Bedford, MA  01730

Phone:  (617) 275-2400

Email:  tbradley@wellfleet.com


Caralyn Brown
Wellfleet Communications, Inc.
15 Crosby Drive
Bedford, MA  01730

Phone:  (617) 275-2400

Email:  cbrown@wellfleet.com

That's the whole thing, bestie! 🌈💅✨