How ARP works: Send a packet from the querrying host with an Ethernet broadcast address asking the target host with the given IP address to respond. All hosts on the physical network receive this packet, and the one with the given IP number responds. Then the original querring host knows the physical address of the target host. Does not use IP; uses's physical frames.
Common ARP improvements: Keep a cache of recently received translations. Remember that these addresses are quite small, and the space needed to store them is also small. Store both the physical and IP addresses of all ARP broadcasting hosts. Then every host who receives a broadcast ARP request can know the address translation of the sender. This is especially imporant for the receiver of the broadcast.
How to Write ARP Software: There are two parts. The first part uses the cache to map IP -> physical addresses. The second part fills the cache with mapping upon request from the first part.
Security: Can you fool ARP software. Yes, by poluting the network with your own answers.
Interesting question: To send machine A some data, you broadcast seeking machine A. Would it not be easier just to broadcast the data. That would for sure reduce the total number of packets sent, at the cost of changing many unicasts to broadcasts. What if someone answers an ARP request for you, and lies about who they are? Who answers an ARP for a machine
How RARP works: The client broadcasts a RARP packet with an ethernet broadcast address, and it's own physical address in the data portion. The server responds by telling the client it's IP address. Note there is no name sent. Also note there is no security. Does not use IP; uses's physical frames.
Common RARP improvements: Don't let an RARP client retry indefinitlly. That just causes wasted broadcasts. Have a backup RARP server or two, on random time delays.
Interesting Question: When should the server broadcast the answer instead of target it? What gets put in the rest of the packet (since there is a large minimum packet length?
How BOOTP works: The client broadcasts a BOOTP packet with source and destination IP broadcast addresses (all 1's), and it's own physical address in the data portion. The server responds by telling the client it's actual IP address, and some other info (see page 368). Note that the server must also send to a broadcast address, since there is no IP-> physical address mapping in the server's ARP cache yet, and the client won't yet respond to ARP requests (since it does not yet recognize it's IP address).
The Boot file: BOOTP sends a suggested file server and file name to the client. The client can then use anbother protocol (TFTP?) to retrieve that file, and boot using the resulting image.
Vendor Specific Area: Can contain anything, but often time of day, dns server name, printer IP address, and such.
Advantages over RARP: Carries more info in the reply.