RFC 1868 (rfc1868) - Page 2 of 4
ARP Extension - UNARP
Alternative Format: Original Text Document
RFC 1868 UNARP November 1995
amount of the IP address space (i.e., all of the hosts contain
addresses on the same subnet, even though they are not directly
attached to the physical network associated with that subnet address.
It is this use of Proxy ARP which produces the problem addressed by
this document.
2. The Problem
Consider the following topology:
+--------+
| Host A |
+--------+
|
======================================== LAN
| |
+--------+ +--------+
| CS1 | comm. servers | CS2 |
+--------+ +--------+
| | | |
+-+ +-+ +-+ +-+
| | | | modems | | | |
+-+ +-+ +-+ +-+
Assume that all of the modems are on the same rotary; that is, when a
remote host dials in, it may be assigned a modem on either of the
communication servers. Further assume that all of the remote hosts'
IP addresses have the same subnet address as the servers and Host A,
this in order to conserve address space.
To begin, a remote host dials into CS1 and attempts to communicate
with Host A. Host A will assume, based on the subnet mask, that the
remote host is actually attached to the LAN and will issue an ARP
Request to determine its hardware address. Naturally, the remote
host will not hear this request. CS1, knowing this, will respond in
the remote host's place with its own hardware address. Host A, on
receiving the ARP Reply, will then communicate with the remote host,
transparently through CS1. So far everything is just fine.
Now, the remote host disconnects and, before Host A can age its ARP
cache, reconnects through CS2. Herein lies the problem. Whenever
Host A attempts to send a packet to the remote host, it will send it
to CS1 because it cannot know that its ARP cache entry is invalid.
If, when the remote host disconnects, the server to which it was
attached could inform other nodes on the LAN that the protocol
address/hardware address mapping was no longer valid, the problem
would not occur.
Malkin Experimental