| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Reverse Address Resolution and the TCP/IP Reverse Address Resolution Protocol (RARP) (Page 2 of 4) The Reverse Address Resolution Protocol (RARP) The first method devised to address the bootstrapping problem in TCP/IP was the backwards use of ARP I mentioned above. This technique was formalized in RFC 903, A Reverse Address Resolution Protocol (RARP), published in 1984. Where ARP allows device A to say I am device A and I have device B's IP address, device B please tell me your hardware address, RARP is used by device A to say I am device A and I am sending this broadcast using my hardware address, can someone please tell me my IP address?.The two-step operation of RARP is illustrated in Figure 52.
The next question then is: who knows A's IP address if device A doesn't? The answer is that a special RARP server must be configured to listen for RARP requests and issue replies to them. Each physical network where RARP is in use must have RARP software running on at least one machine. RARP is not only very similar to ARP, it basically is ARP. What I mean by this is that RFC 903 doesn't define a whole new protocol from scratch, it just describes a new method for using ARP to perform the opposite of its normal function. RARP uses ARP messages in exactly the same format as ARP, but uses different opcodes to accomplish its reverse function. Just as in ARP, a request and reply are used in an exchange. The meaning of the address fields is the same too: the sender is the device transmitting a message while the target is the one receiving it.
Home - Table Of Contents - Contact Us The TCP/IP Guide (http://www.TCPIPGuide.com) Version 3.0 - Version Date: September 20, 2005 © Copyright 2001-2005 Charles M. Kozierok. All Rights Reserved. Not responsible for any loss resulting from the use of this site. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||