RFC 1868

ARP Extension - UNARP

📅 published November 1995, from ietf

RFC 1868: ARP Extension - UNARP 🦋

okay bestie, so this one is an Experimental doc from November 1995 🌸 written by Gary Scott Malkin (G. Malkin) at Xylogics, Inc., published through the Network Working Group. it doesn't say it obsoletes or updates anything, so it's just vibing on its own ✨

Status of This Memo

okay quick legal-ish bit 💅 this memo defines an Experimental Protocol for the Internet community. it does not specify an Internet standard of any kind. discussion and suggestions for improvement are requested 🫶 and distribution of this memo is unlimited 🌈

Abstract

the Address Resolution Protocol lets an IP node figure out the hardware (datalink) address of a neighboring node on a broadcast network 🧚 the protocol leans on timers to age away old ARP entries 💀 this doc is a trivial tweak to the ARP mechanism (not the packet format!) that lets a node announce it's leaving the network, so every other node updates its ARP tables to match. iconic 👑

Acknowledgements

big thanks to James Carlson/Xylogics for reviewing this doc and proposing the backwards compatibility mechanism 💖

1. Introduction ✨

so the main job of ARP, as defined in [1], is figuring out a node's hardware address from its network address (protocol address in ARPspeak 🤓). the ARP protocol specifically says nodes should not periodically advertise their existence, and there are two reasons for that. first, it would generate a lot of network traffic and table maintenance overhead 😩 second, it's highly unlikely that all nodes will need to talk to all other nodes. since a node doesn't advertise its existence, it doesn't advertise its imminent departure either. this isn't a serious problem, since most ARP implementations run timers to age away old entries, and departing nodes seldom leave gracefully anyway 🙈

then ARP got a new use: Proxy ARP 🎀 some people think Proxy ARP is an evil thing 😤 but it does serve a purpose! it allows communication in ways never considered in the original IP architecture. for example, it lets dial-in hosts connect to a network without eating a huge chunk of the IP address space (all the hosts have addresses on the same subnet, even though they aren't directly attached to the physical network associated with that subnet address). this Proxy ARP use is exactly what creates the problem this doc is fixing 💅

2. The Problem 🍓

here's the topology, it's giving diagram energy:

                    +--------+
                    | Host A |
                    +--------+
                        |
      ======================================== LAN
          |                             |
      +--------+                    +--------+
      |  CS1   |   comm. servers    |  CS2   |
      +--------+                    +--------+
        |    |                        |    |
       +-+  +-+                      +-+  +-+
       | |  | |       modems         | |  | |
       +-+  +-+                      +-+  +-+

so picture all the modems on the same rotary 🎡 meaning when a remote host dials in, it might get assigned a modem on either communication server. also, all the remote hosts' IP addresses share the same subnet address as the servers and Host A, just to conserve address space 🧠

okay storytime. a remote host dials into CS1 and tries to talk to Host A. Host A looks at the subnet mask, decides the remote host is attached to the LAN, and sends an ARP Request to find its hardware address. the remote host obviously won't hear that request 🙃 so CS1 answers on the remote host's behalf with its own hardware address. Host A gets the ARP Reply and happily talks to the remote host, transparently through CS1. so far, everything is just fine 🥹

plot twist 😱 the remote host disconnects and, before Host A ages its ARP cache, reconnects through CS2. whenever Host A tries to send a packet to the remote host, it sends it to CS1, because it has no way of knowing that its ARP cache entry is now invalid. if the server the remote host was attached to could tell the other nodes on the LAN, when the remote host disconnects, that the protocol address/hardware address mapping is no longer valid, this problem wouldn't happen at all ✨

3. The Solution 🧚

when a server (like the ones above) disconnects from a remote host it responded to with Proxy ARP, it broadcasts an UNARP 📣 an UNARP is an unsolicited ARP Reply with the following field values:

Hardware Address Space       as appropriate
Protocol Address Space       0x800 (IP)
Hardware Address Length      0 (see Backwards Compatibility)
Protocol Address Length      4 (length of an IP address)
Opcode                       2 (Reply)
Source Hardware Address      Not Included
Source Protocol Address      IP address of detaching host
Target Hardware Address      Not Included
Target Protocol Address      255.255.255.255 (IP broadcast)
NOTE: this is a 16-byte packet (not including MAC header) 📏

when a node receives an UNARP, it deletes the ARP cache entry associated with that IP address 🗑️

a server doesn't strictly need to track whether it actually sent a Proxy ARP Reply 🤷‍♀️ it would be enough for the server to always send an UNARP whenever a remote host disconnects.

and of course, there's no reason a host that gracefully detaches from a LAN can't also send an UNARP for itself 💅 this is especially useful if, when it re-attaches, it might have a different hardware address.

4. Backwards Compatibility 🫶

the changes to support UNARP are trivial, so there's every expectation it'll be widely supported 🌈 but obviously there's going to be a period where nodes that support UNARP coexist with nodes that don't. to stop unenlightened nodes from adding spurious ARP cache entries with hardware addresses of zero, UNARP packets specify a hardware address length of zero 🙅‍♀️ nodes that don't support UNARP should reject this. as a result, the source and target hardware address fields simply don't exist in UNARP packets (as described above) 👀

it is recommended that implementors include a configuration switch to disable UNARP, just in case some vendor's ARP implementation takes offense at the abbreviated UNARP packet format 😭

5. Security Considerations 💀

security issues are not discussed in this memo. the memo itself says nothing on that topic 🙈

References

[1] Plummer, D., "An Ethernet Address Resolution Protocol", STD 37, RFC 826, MIT, November 1982.

Author's Address 💜

Gary Scott Malkin
Xylogics, Inc.
53 Third Avenue
Burlington, MA  01803

Phone:  (617) 272-8140
EMail:  gmalkin@xylogics.com
📦 where this page comes from