On 13 Jan 2006, in the Usenet newsgroup comp.os.linux.networking, in article
>This ia actually the job of the reverse address resolution
>protocol(rarp). Google for it to find out more information if you so
>desire.
0903 Reverse Address Resolution Protocol. R. Finlayson, T. Mann, J.C.
Mogul, M. Theimer. Jun-01-1984. (Format: TXT=9345 bytes) (Also
STD0038) (Status: STANDARD)
This protocol is handled by a 'rarpd' server that may or may not be part
of the distribution. Red Hat/Fedora has been supplying rarpd-ss981107 for
several years. RFC0903 is widely available on many web server world wide.
Quote:>However, this rarp protocol will not apply to your scenario becuase there
>are no static address assignments.
1931 Dynamic RARP Extensions for Automatic Network Address
Acquisition. D. Brownell. April 1996. (Format: TXT=27544 bytes)
(Status: INFORMATIONAL)
Likewise, depending on a user supplied string (here, the MAC address which
can easily be changed) isn't the greatest security feature. RFC1931 should
also be available at the same place you find RFC0903.
Quote:>Now this whole process is dependent on a few things:
>1. You are capable of sending broadcasts to the internal subnet. It may
>be rejected from a external router or firewall through ingress rules.
1a. The remote systems may not respond to a 'broadcast' ping. Some O/S
do this to avoid DOS or broadcast storms.
Quote:>2. Host resident firewalls may deny echo_requests.
However, if the individual address is pinged, the remote hosts will almost
always respond to the ARP request that precedes the ICMP echo. The
exception would be if the remote is filtering on MAC addresses in a modified
network stack. (ARP is normally at a "lower" level in the stack than the
firewall code.) Thus, the "remote" hardware address will almost always be
available in the ARP cache.
Old guy