RFC 1868 (rfc1868) - Page 3 of 4

ARP Extension - UNARP

RFC 1868                         UNARP                     November 1995


3. The Solution

   When a server, as described above, disconnects from a remote host for
   which it has responded to a 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)

   On receiving an UNARP, a node deletes the ARP cache entry associated
   with the IP address.

   It is not strictly necessary that a server keep state information
   about whether or not it has actually sent a Proxy ARP Reply; it would
   be sufficient if a server always sends an UNARP when a remote host
   disconnects.

   Of course, there is no reason why a host which gracefully detaches
   from a LAN cannot also send an UNARP for itself.  This would be
   especially useful if, upon re-attaching, it might have a different
   hardware address.

4. Backwards Compatibility

   The modifications to support UNARP are trivial, so there is every
   expectation that it will be widely supported.  Of course, there will
   be a period of time during which nodes which support UNARP will
   coexist with nodes which do not support UNARP.  To prevent
   unenlightened nodes from adding spurious ARP cache entries with
   hardware addresses of zero, UNARP packets specify a hardware address
   length of zero.  This should be rejected by nodes which do not
   support UNARP.  As a consequence of this, the source and target
   hardware address fields do not exist in UNARP packets (as previously
   described).

   It is recommended that implementors include a configuration switch to
   disable UNARP in the event that some vendor's ARP implementation
   might take offense at the abbreviated UNARP packet format.




Malkin                        Experimental