Alright all you cheaters!

[The Wraith]

Don't think I can't tell a cut-n-pasted answer from an 'off your brain' answer! You may not look up your answers in a book, the Internet, or any other source of reference. If there were 10 people reading the acronyms of the day, all 10 people could go hit the net and find the answer. Easily. There's no challenge in it.

Keep in mind, I don't expect highly technical answers to what the acronyms' definition is. Layman's terms is what I looking for.

Why?

Because anyone can search the net and find the technical answer, it doesn't mean that they are any closer to understanding what it is they just read. Sure, lots of people can learn through reading - but not everyone is that inclined to have the information soak into their brain. By answering the 'question' in your own words, even though it might not be 100% accurate, you might even actually learn a bit more about the subject rather than doing a quick search, cutting, pasting, then forgetting what it was you just pasted.

I have lots of RFC numbers and context memorized. Lots... And it's no task for me to go to www.rfc-editor.org and search for ones I don't know. Taking the 2 minutes it takes to find, cut-n-paste, and forget the information does nothing. I know and you know how easy it is to find information on the Internet. If you're going to merely cut-n-paste your "knowledge" I might as well include a URL in the post which contains the acronym, so you don't waste any excessive time looking for what you're passing off as your own knowledge.

In case there is any question, you may not employ any aid of references in the answering of this acronym trivia! Ya damn cheaters.

Regards,
The Wraith

[[AK]Palooka]

To clarify, my response to the acronym of the day was not simply a cut-and-paste job; it is, in fact, completely in my own words. I just consulted a few different sources and threw the answer together. However, I do, for the most part, understand the answer that I gave. Sure, none of it was from my own knowledge (although I have seen that acronym before while perusing networking books), but how many of us would have been able to define and explain RARP off the tops of our heads? From what I understand, the protocol is obsolete to begin with, and it is certainly obscure compared to yesterday's acronym, which I'm sure almost any of us could have defined and explained. If your objective is to facilitate the gaining of networking knowledge, then I would say it was successful today, as I did learn something through my research of the subject.

------------------
[AK]Palooka
August Knights Administrator
Xearic: 48 Necromancer
Burwell: 40 Cleric

[The Wraith]

Well you see, Palooka, whatever references you...referenced, didn't teach you anything about RARP at all. How do I know this? When you say, "from what I understand, the protocol is obsolete to begin with..."

RARP is a critical function of networking. It's not a protocol, as far as networking protocols go - it's a protocol as far as a "process". Certain functions of internetworking would not be possible if there was no RARP. Same goes for ARP.

In order for two machines to communicate over a network it needs to know the Layer 3 address and MAC address of the node it wishes to talk to. ARP and RARP fill in those two holes as necessary, depending on which is unknown during the time of communication. There's nothing obsolete about it.

RARP = Get an IP address when only a MAC address is known.
ARP = Get a MAC address when only an IP address is known.

Regards,
The Wraith

[[AK]Palooka]

I beg to differ, Wraith. From what I've read, RARP is becoming obsolete due to the widening usage of BOOTP (particularly BOOTP in tandem with DHCP), because it is more efficient, and provides more information. RARP only supplies an IP address, while BOOTP supplies not only an IP address, but also the address of the default gateway, the address of the bootstrap image server, and vendor-specific hardware information and subnet masks. In addition, RARP requires direct access to hardware, and it cannot be used in networks that dynamically assign hardware addresses.

------------------
[AK]Palooka
August Knights Administrator
Xearic: 48 Necromancer
Burwell: 40 Cleric

[The Wraith]

BOOTP is a protocol that lets a network user be automatically configured (receive an IP address) and have an operating system boot or initiated without user involvement. The BOOTP server, managed by a network administrator, automatically assigns the IP address from a pool of addresses for a certain duration of time. BOOTP (and BOOTP servers) are nothing more than DHCP servers on steriods.

BOOTP is the basis for a more advanced network manager protocol, the Dynamic Host Configuration Protocol. It doesn't even directly relate to the ARP/RARP process. Even IF every DHCP server was replaced with BOOTP servers...the still need ARP/RARP processes.

So, you have a machine connected to a BOOTP supported infrastructure. You power on the machine, it contacts the BOOTP server, get's an IP address config, get's a default gateway config. Done. You pop open your web browser and type "www.augustknights.com" - your machine needs to perform an ARP/RARP to determine the IP and MAC address of the webserver before it can communicate. augustknights.com also needs to know your machine's IP and MAC address before it can reply.

This whole process has nothing to do with BOOTP, it's an entirely different "thing". BOOTP servers do NOT contain databases of information concerning hostname records of remote machines. They may have a small arp cache built in to lower response times to lookups but they are NOT replacements to ARP/RARP processes.

When I click "Submit reply", if my BeOS machine doesn't know the IP/MAC address of augustknights.com server it will have to perform an ARP or RARP request (depending on what it doesn't know) before it knows how to send the data. I can configure this machine to get it's IP and gateway via BOOTP and I STILL need to perform an ARP / RARP request if I don't have associated IP / MAC address info. They are discontiguous concepts...see?

You're not understanding what a ARP or RARP request is. I know this for a fact when you say, "and it cannot be used in networks that dynamically assign hardware addresses." because it's both an incorrect statement and completely dis-associated with addressing schemes. Here, let me take you through the process in VERY SIMPLE form.

1. Power on machine
2. Machine boots up and get's network config.

( either from manual configuration, DHCP servers, BOOTP servers, etc - SOMEHOW it get's an IP address, a subnet mask, a default gateway, etc ...everything it needs to communicate on a network )

3. You use this machine to communicate to some other machine, webserver, file server, whatever.

( let's use web browsing as the example )

4. You type www.augustknights.com, before your computer can communicate to the server it needs to know how to get TO the server - it "learns" this through knowing the servers' IP address and MAC address.

( let's say your machine has no information on ak.com )

5. Your machine sends out a specific type of packet called an ARP request for "augustknights.com".

6. Some name resolution takes place which converts "augustknights.com" to an IP address. Most likey DNS but could be a WINS server in a Microsoft environment.

7. Machine says, "ok, I know the IP - now I need the MAC address". Your machine, through the process of routed networks (which isn't within the scope of this example) traverses various network until it gets to augustknights.com.

8. augustknights.com receives an ARP packet which says to it, "Tell me your MAC address, send that info to MY IP and MY MAC (included in packet").

9. augustknights.com sends a reply to your machine's request which contains it's MAC address.

10. Your machine receives this request reply and is now capable of sending data to augustknights.com.

11. Data starts being sent...

...and that's how ARP is used. (basically - skipped several steps) As you can see, it has nothing to do with HOW your local machine received it's IP address configuration. It's not even related. When an incoming packet destined for a host machine on a particular local area network arrives at a gateway, the gateway asks the ARP program to find a physical host or MAC address that matches the IP address. It looks in the ARP cache and, if if finds the address, provides it so that the packet can be converted to the right packet length and format and sent to the machine. If no entry is found for the IP address, ARP broadcasts a request packet in a special format to all the machines on the LAN to see if one machine knows that it has that IP address associated with it. A machine that recognizes the IP address as its own returns a reply so indicating. ARP updates the ARP cache for future reference and then sends the packet to the MAC address that replied.

Regards,
The Wraith

* oops, signed my name twice.

[This message has been edited by The Wraith (edited 09-28-2000).]