RARP requests

I wont bother given too much background explanation into this query - because anyone who can satisfactorily answer it won't need any.

Why are special RARP servers necessary?

If a RARP server is the only device on a LAN to be able to send a RARP response back to a source host, then why does that same source have to send its request in a broadcast?

Again .......... if a source has to send a RARP query in broadcast why then is there need for a special RARP server, and if a RARP server is necessary then why does the source have to bother sending its request as a broadcast ........... this may seem blatantly obvious to some but to me it seems either redundant or contradictory - haven't figured out which yet ......

Thanks, in advance to all responses.

Hi

I hope I understood you correctly. I try to elaborate.

Assume a simpler device knows only how to boot up and its
MAC address (data-link layer). It might know about the RARP server,
but usually does not. How does this device then get its IP address
in order to be able to communicate using IP (higher layer: network layer)?
So that simple device performs a RARP broadcast. Each system on the
"LAN" gets that request, but only (hopefully) the RARP server will answer
by providing an IP address to the device.

This step is not redundant, since the device might not know about
DHCP etc., neither does it know about the RARP server.

/edit:Check out webopedia.com as well[1] and the RFC903[2] (one of
the shortest RFC's :) )

Quote:

---

This RFC suggests a method for workstations to dynamically find their
protocol address (e.g., their Internet Address), when they know only
their hardware address (e.g., their attached physical network
address).

---

Cheers.

[1] http://www.webopedia.com/TERM/R/RARP.html
[2] http://www.ietf.org/rfc/rfc0903.txt?number=903

Maybe I didn't explain myself well enough ...........

I know about RARP requests and responses and who sends and recieves them .......... but my confusion is why, if only the server can respond, does the source need to send its request in broadcast (to all units on the LAN) and if it has to send a broadcast why can only the server respond - it seems to me that either the broadcast is 'overkill' or the RARP server is 'overkill'.

Also, it seems that by broadcasting a query (that only the server can answer) it is needlessly utilizing LAN bandwidth and hardware and even potentially creating 'collision regions' (in Ethernet) within the LAN. And if its a token key LAN would the token have to drop off all requests before it could eventually return to the server for the response?

It just seems that it could all be accomplished more efficiently ....... so why isn't it?

Its like asking a class of kids a question that only the principle is authorized to answer.

I have read the RFC posted and secware is right - it is one of the shortest ones ......

Unfortunalely it didn't answer my question as to Why??? it is set up like this.

Hi

As said: The simple device does not know about the RARP server. It can't directly
address a frame (not even to talk about packets) to the RARP server, therefore
it needs to perform a broadcast. There are a lots of broadcasts in the booting up
process of OSs. If they simply do not know, who is responsible for this and that,
they ask all. Since the traffic is in the subnet only and (often) happens only once,
the overhead is minimal, and the collision problem is, here, not an issue.
However, there might be an issue of integrity of the answer. Can you trust the
source who provided you with the answer. (R)ARP are "trusting" protocols. There
is no authentication process involved.

To use a similar analogy: You have a couple of kids in your class room. You have a question
for Shirley. If you would know who Shirley is, you could just address to her. But since you
don't, you shout in the class room "Shirley, could you please tell me...". A moment later, you
will know who Shirley is, and in addition, you have answered your question. Or something
like this :)

Cheers.

Yes now I see what you are saying and it makes more sense now that I realize that the source doesn't actually know about the server ......... But maybe now you can answer this one .....

Why doesn't it know about the RARP server? Shouldn't a sysadmin set it up so that each LAN host knows about the RARP server so as to alleviate the need to broadcast across the entire LAN or subnet?

And another question ..... this may seem ignorant to some and I apologize to them - but to me its an intelligent question .........

Why would a host not know its own IP, I mean what are some scenarios that would lead to a host not knowing its own IP.
I can understand that a host may sometimes not be able to ascertain a MAC (physical hardware address), but would just like to be completely clarified on this subject

THE REASON FOR MY MOOD DOES MENTION THAT I AM OF THE CURIOUS VARIETY .....LOL

Hi

It is a good question. Assume (the standard example) a diskless workstation. The
information of the MAC address is part of its hardware - it's burned there, so it
can send it on the data link layer.
How should a diskless workstation know about the IP range the LAN is configured on?
Is it 192.168.0.0 or 192.168.1.0 or ... ? It cannot know - because it can be different
wherever that diskless workstation is attached on... The same holds for the RARP server:
How do you imprint that variable information on the diskless workstation? :)
Cheers

Yes yes

I see what your saying ........... So would it be safe to assume that all diskless workstations have dynamic (variable) IPs?

Hi

The design of a RARP server is not trivial, since it is often implemented as a user process
rather than part of the kernel's implementation (has to read disk files). Furthermore,
often several RARP servers are implemented for redundancy, and we come back to a
probable collision problem, as you mentioned it.

Because of such reasons, static IP's are given to diskless systems (maintained manually),
but I could not swear on it, since nowaday BOOTP and DHCP has become standard rather
than RARP.

Cheers.

I will look into this that we are both uncertain about .............

Let you know what I find when I find it .......

Thanks for everything