Printable View
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".
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. :)
That is interesting, also I could not find it.Quote:
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
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
Yes I agree.Quote:
Cisco docs aren't always 100% accurate either
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. :)
Any idea why the unicat issue for RARP reply has not been mentioned in RFC ?Quote:
Most RARP implementations would probably do the same thing since they're similar-looking and similarly-named protocols.
Can we consider that the information about RARP reply which has been mentioned in the book is not accurate?
The authors probably just plain forgot. :)Quote:
Originally Posted by zillah
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.Quote:
Can we consider that the information about RARP reply which has been mentioned in the book is not accurate?
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. :)