RARP request and reply

[zillah]

If I have got this scenario, router with 2 hubs each hub belongs to one LAN, with each LAN I have got 3 PCs.

RARP request is broadcast address, that mean each PC takes copy of RARP request frame to check it.

Now with RARP reply which is unicast address, each PC should not taken copy of the frame, because it is unicast.

Why does cisco say about RARP reply:
"All computers copy the frame and examine it".

[Tuttle]

How do you know that the RARP reply is unicast? The best spec I could find for RARP is RFC 903, which doesn't actually specify whether replies should be sent unicast or broadcast. Either will work in an implementation -- unicast only provides the mapping to the client which is requesting an address, broadcast would also provide that mapping to other hosts on the segment for possible later reference.

Cisco docs aren't always 100% accurate either; sometimes not even Cisco can say for sure how Cisco equipment behaves.

[zillah]

How do you know that the RARP reply is unicast? The best spec I could find for RARP is RFC 903, which doesn't actually specify whether replies should be sent unicast or broadcast

That is interesting, also I could not find it.

I have got 3 books all of them saying that RARP reply is unicast.

(TCP/IP Protocol suite), by Forouzan, page 173 sec7.3

"The RARP request packets are broadcast; the RARP reply packets are unicast"

see the power point slide for the above book in this link:

http://www.mhhe.com/engcs/compsci/fo...tcpipppt.mhtml

download chapter 8 and see figure 8-8



And in other book which is (Data Communications and Networking), By same author Forouzan
http://highered.mcgraw-hill.com/site...ew0/chapter20/

Third point :An ARP reply is unicast to the host requesting the mapping.

Here he is talking about ARP (not RARP) reply.

The other two books are not with me right now


See also this link:
http://www.tcpipguide.com/free/t_Rev...AddressR-3.htm

Cisco docs aren't always 100% accurate either

Yes I agree.

[Tuttle]

ARP replies are definitely unicast -- RFC 826 says that replies should be sent to "the (new) target hardware address on the same hardware on which the request was received." Most RARP implementations would probably do the same thing since they're similar-looking and similarly-named protocols. But you can't count on it.

[zillah]

Most RARP implementations would probably do the same thing since they're similar-looking and similarly-named protocols.

Any idea why the unicat issue for RARP reply has not been mentioned in RFC ?

Can we consider that the information about RARP reply which has been mentioned in the book is not accurate?

[Tuttle]

Any idea why the unicat issue for RARP reply has not been mentioned in RFC ?

The authors probably just plain forgot.

Can we consider that the information about RARP reply which has been mentioned in the book is not accurate?

I would guess that most real-world implementations would use unicast, simply because that's what ARP does. Books therefore would describe the RARP replies as being unicast.

If you're really interested, set up a little RARP environment and a protocol analyzer like Ethereal or tcpdump and see what gets put on the wire.